[Bf-committers] New Developer Meeting minutes

[joe]

I wasn't saying we should abandon support for projectfiles.  My point
is that cmake must perform on the command line build workflow as well
as project file workflows.  And that support for projectfiles doesn't
make it great for command line (and vice versa).

I wasn't advocating generating project files from our scons system,
heh.  I'm all for replacing scons, actually, either by rewriting our
scons wrapper and infrastructure to use waf, or replacing it with
cmake if cmake is good enough.

Joe

On Mon, Jan 11, 2010 at 2:10 PM, Erwin Coumans <erwin.coumans at gmail.com> wrote:
>>> it (cmake) may generate project files, but I don't use that
>
> It sounds a little bit selfish, there are many developers who want to use
> project files.
>
>>> and our scons setup could be setup to do the same thing as well.
>
> Can scons create decent MSVC and Xcode project files? Who maintains such
> project generation?
>
> Thanks,
> Erwin
>
>
> 2010/1/11 joe <joeedh at gmail.com>
>
>> Does it run automatically or do you have to run it yourself?
>>
>> Joe
>>
>> On Mon, Jan 11, 2010 at 1:53 PM, Campbell Barton <ideasman42 at gmail.com>
>> wrote:
>> > @joe, From my experience cmake doesnt require you to do more clean
>> > builds then scons. The only thing is is dependencies change "cmake ."
>> > needs to run again in the build dir, building after only does a
>> > partial build like scons.
>> >
>> > If I understand this correctly, only generating the Makefiles is
>> > slower with GLOB, not running the subsequent make's (else it should
>> > find the new C/H files also).
>> >
>> > re: defining all files, not having to re-run "cmake ." would be nice
>> > but Im not that fussed, if we only used CMake, maintaining the file
>> > lists might not be so hard, but is some dev adds a file and they use
>> > another build system its annoying for them to have to update the CMake
>> > files (think msvc project files).
>> >
>> > On Mon, Jan 11, 2010 at 10:41 PM, joe <joeedh at gmail.com> wrote:
>> >> On Mon, Jan 11, 2010 at 10:10 AM, Erwin Coumans <
>> erwin.coumans at gmail.com> wrote:
>> >>> Just don't complain that dependencies don't reliably work, or that
>> >>> cmake is a bit slow :-)
>> >>>
>> >>> I follow the advice of the CMake developers for the Bullet project,
>> >>> and I'm happy with it.
>> >>
>> >> This isn't convincing me that CMake is any better then anything else;
>> >> it may generate project files, but I don't use that, and our scons
>> >> setup could be setup to do the same thing as well.  I care very much
>> >> about dependencies, mostly because I can't afford to do clean builds
>> >> as often as is often necessary in a build system with unreliable
>> >> dependency updates (old, crappy hardware is just too slow to do that).
>> >>
>> >> Joe
>> >>
>> >> On Mon, Jan 11, 2010 at 10:10 AM, Erwin Coumans <
>> erwin.coumans at gmail.com> wrote:
>> >>> >From the CMake mailinglist:
>> >>>
>> >>> http://www.cmake.org/pipermail/cmake/2009-July/030535.html
>> >>>
>> >>>
>> >>> "The problem with globbing is that CMake has no way to determine that
>> new
>> >>>
>> >>> source (or header) files were added to a directory, other than ALWAYS
>> >>> running when someone types 'make' (or the VS equivalent). This is not
>> >>> really desirable behaviour, because oftentimes no new files will have
>> >>> been added. And therefore, that's not how CMake behaves.
>> >>>
>> >>> So, in general, when using globbing, YOU are responsible for rerunning
>> >>> CMake whenever you've added a source file. Otherwise you run the risk
>> of
>> >>> the new file not being compiled. Furthermore, you might accidentally
>> >>> compile sources that were just lying around in your directory as test
>> >>> code. Deletion of sources can also cause interesting effects if you
>> >>> create a library, because the object will remain in that library until
>> >>> you (manually) remove and recreate the library.
>> >>>
>> >>> I hope my examples convinced you enough that globbing is (in general) a
>> >>> bad idea."
>> >>>
>> >>>
>> >>> Re-running cmake each time to recognize new/deleted headerfiles
>> >>> doesn't seem efficient,
>> >>>
>> >>> but if developers prefer ease of use at the cost of some performance
>> >>> you might want to use GLOB.
>> >>>
>> >>>
>> >>>
>> >>> 2010/1/11 Erwin Coumans <erwin.coumans at gmail.com>
>> >>>
>> >>>> The stackoverflow answer seem to confirm there are some dependencies
>> and
>> >>>> performance issues with GLOB.
>> >>>>
>> >>>> I'm interested to hear what the 'official' recommendation is by the
>> cmake
>> >>>> developers.
>> >>>> Cheers,
>> >>>> Erwin
>> >>>>
>> >>>>
>> >>>> 2010/1/11 José Ignacio <jose.cyborg at gmail.com>
>> >>>>
>> >>>> On Mon, Jan 11, 2010 at 1:17 PM, Erwin Coumans <
>> erwin.coumans at gmail.com>
>> >>>>> wrote:
>> >>>>> > The is no problem using GLOB with a wildcard, as I mentioned at
>> least
>> >>>>> > times in this thread ;)
>> >>>>> >
>> >>>>> > But explicitly listing each file seems recommended, I forgot why.
>> >>>>> > Perhaps GLOB needs to search for (potential) new headerfiles, every
>> >>>>> > time you build and a .cpp changed (slowing down things
>> unnecesarily)?
>> >>>>> >
>> >>>>> > Perhaps reading the docs, using google or asking on the cmake
>> >>>>> > mailingslist will tell why GLOB can better be avoided in
>> CMakeLists.txt?
>> >>>>> >
>> >>>>> IIRC, if you use globbing and added a new file after you build for
>> the
>> >>>>> first time, it won't take it into account for the next call of "make"
>> >>>>> unless you touch the CMakeLists.txt file or clear the cache and
>> >>>>> rebuild. (though maybe that behavior changed on newer versions of
>> >>>>> cmake)
>> >>>>>
>> >>>>> oh, a google search gave me this link:
>> >>>>>
>> >>>>>
>> http://stackoverflow.com/questions/1027247/best-way-to-specify-sourcefiles-in-cmake
>> >>>>>
>> >>>>> > Cheers,
>> >>>>> > Erwin
>> >>>>> >
>> >>>>> _______________________________________________
>> >>>>> Bf-committers mailing list
>> >>>>> Bf-committers at blender.org
>> >>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>>>>
>> >>>>
>> >>>>
>> >>> _______________________________________________
>> >>> Bf-committers mailing list
>> >>> Bf-committers at blender.org
>> >>> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>>
>> >> _______________________________________________
>> >> Bf-committers mailing list
>> >> Bf-committers at blender.org
>> >> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>
>> >
>> >
>> >
>> > --
>> > - Campbell
>> > _______________________________________________
>> > Bf-committers mailing list
>> > Bf-committers at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>