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 <[email protected]> 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 <[email protected]> > >> 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 <[email protected]> >> 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 <[email protected]> >> > >> >> Does it run automatically or do you have to run it yourself? >> >> >> >> Joe >> >> >> >> On Mon, Jan 11, 2010 at 1:53 PM, Campbell Barton <[email protected]> >> >> 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 <[email protected]> wrote: >> >> >> On Mon, Jan 11, 2010 at 10:10 AM, Erwin Coumans < >> >> [email protected]> 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 < >> >> [email protected]> 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 <[email protected]> >> >> >>> >> >> >>>> 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 <[email protected]> >> >> >>>> >> >> >>>> On Mon, Jan 11, 2010 at 1:17 PM, Erwin Coumans < >> >> [email protected]> >> >> >>>>> 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 >> >> >>>>> [email protected] >> >> >>>>> http://lists.blender.org/mailman/listinfo/bf-committers >> >> >>>>> >> >> >>>> >> >> >>>> >> >> >>> _______________________________________________ >> >> >>> Bf-committers mailing list >> >> >>> [email protected] >> >> >>> http://lists.blender.org/mailman/listinfo/bf-committers >> >> >>> >> >> >> _______________________________________________ >> >> >> Bf-committers mailing list >> >> >> [email protected] >> >> >> http://lists.blender.org/mailman/listinfo/bf-committers >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > - Campbell >> >> > _______________________________________________ >> >> > Bf-committers mailing list >> >> > [email protected] >> >> > http://lists.blender.org/mailman/listinfo/bf-committers >> >> > >> >> _______________________________________________ >> >> Bf-committers mailing list >> >> [email protected] >> >> http://lists.blender.org/mailman/listinfo/bf-committers >> >> >> > _______________________________________________ >> > Bf-committers mailing list >> > [email protected] >> > http://lists.blender.org/mailman/listinfo/bf-committers >> > >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
