[Bf-committers] New Developer Meeting minutes

[joe]

That's what I was trying to figure out, whether it's as good as scons
or not.  It sounds like it might be comparable, so I'm going to try it
as soon as I get time.  If it is, I'll be very happy, since for all
it's ease of use and maintenance, scons really is super slow.

Joe

On Mon, Jan 11, 2010 at 2:30 PM, Erwin Coumans <erwin.coumans at gmail.com> wrote:
> ah, ok, I would have been interested in open source scons project file
> generation.
>
> (actually at Havok we had scons create cross-platform project files,
> but these extensions were kept in-house)
>
> As far as I know, cmake works very well for both command line and
> projectfiles.
>
> I still haven't heard a convincing argument of scons features that cmake
> doesn't have.
> GLOB works fine (even though manual is better)
>
> How is cmake not good enough?
> Thanks,
> Erwin
>
>
>
>
> 2010/1/11 joe <joeedh at gmail.com>
>
>> 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
>> >
>> _______________________________________________
>> 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
>