[Bf-committers] New Developer Meeting minutes

Campbell Barton ideasman42 at gmail.com
Mon Jan 11 22:53:29 CET 2010


@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


More information about the Bf-committers mailing list