[Bf-committers] Re: handcrafted makefiles, autotools,
scons and cmake ?
jlp at nerim.net
Mon Oct 30 22:50:00 CET 2006
Le 29 oct. 06 à 17:14, Jean-Luc Peurière a écrit :
> Le 26 oct. 06 à 12:57, Jacques Beaurain a écrit :
>> On activity since September 19: I am a little reluctant spending a
>> more time on this if I don't get buy-in from the Blender dev
>> community. I can easily maintain the CMake files for my own use (Mac
>> OSX and Windows) this side, but I don't see it reaching a fully
>> polished state that is useful for everybody and all platforms if
>> it is
>> going to stay outside CVS.
> we discussed in meeting about it.
> i will test (time permitting) carefully.
> i personally think it is interesting, but we need to be sure of the
> for all platforms.
> I will report findings here
I had a bit of time to play with this on sunday and monday evenings
on Os X with makefiles and
xcode, so my first impressions are as follow :
- First, the system is very nice, you run cmake once and after that,
the generated makefiles
or xcode projects are intelligent enough to detect that the cmake
files have changed and react
accordingly. Which means you deal with the usual makefiles or
xcode projects use shell scripts to check the cmake config have
- the generated makefiles and projects are mostly fine (other systems
like JAM generate a lot
of garbage, but not cmake), you get the ability to rebuild any of
the libs of blender individually.
there is some mess in the form of cached datas but they are cleanly
kept in the build tree in their
- it is easy to keep the tree clean of the build objects.
- there were some errors for unix makefiles (find openal took the
framework version, which
don't comprise alut , some includes in intern, and dna.c is generated
at the wrong place,
so i had a blender compiled with an outdated dna.c)
- GLOB syntax means that extending to new files is easy and most of
the time automatic
- no player yet
- we need an equivalent to the user-def.mk
-build speed is very nice (i would say even faster than with standard
makefiles), and progress report is
- install and bundle target (the latter for os x) are MIA (yes i
- macos x bundle is incomplete at the time.
- I already hate the ALL_IN_CAPS syntax. However the grammar is very
simple but rich.
- I don't like the fact that the documentation is only a long list of
available functions and modules besides a (paid) book
- I need to be able to turn on and off verbose output
All in all, this confirm to be very interesting.
It is a bit early to verify the robustness of the system (although i
have few worries).
What we need to know now is how robust it is for the various
configurations in the windows world.
This, i cannot answer.
Also, before inclusion in cvs, i would like to see a finished project.
One of the good leads is that it seems easy to support separate build
trees for various options in same
cvs tree. With current make, i need several cvs trees for that
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bf-committers