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 <joe...@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.coum...@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 <joe...@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 <ideasma...@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 <joe...@gmail.com> wrote: > >> >> On Mon, Jan 11, 2010 at 10:10 AM, Erwin Coumans < > >> erwin.coum...@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.coum...@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.coum...@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.cyb...@gmail.com> > >> >>>> > >> >>>> On Mon, Jan 11, 2010 at 1:17 PM, Erwin Coumans < > >> erwin.coum...@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@blender.org > >> >>>>> http://lists.blender.org/mailman/listinfo/bf-committers > >> >>>>> > >> >>>> > >> >>>> > >> >>> _______________________________________________ > >> >>> Bf-committers mailing list > >> >>> Bf-committers@blender.org > >> >>> http://lists.blender.org/mailman/listinfo/bf-committers > >> >>> > >> >> _______________________________________________ > >> >> Bf-committers mailing list > >> >> Bf-committers@blender.org > >> >> http://lists.blender.org/mailman/listinfo/bf-committers > >> >> > >> > > >> > > >> > > >> > -- > >> > - Campbell > >> > _______________________________________________ > >> > Bf-committers mailing list > >> > Bf-committers@blender.org > >> > http://lists.blender.org/mailman/listinfo/bf-committers > >> > > >> _______________________________________________ > >> Bf-committers mailing list > >> Bf-committers@blender.org > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > > _______________________________________________ > > Bf-committers mailing list > > Bf-committers@blender.org > > http://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers