[Bf-committers] New Developer Meeting minutes

Mon Jan 11 23:30:05 CET 2010

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
>