[Bf-committers] New Developer Meeting minutes

[joe]

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
>