[Bf-committers] Re: handcrafted makefiles, autotools, scons and cmake ?

[Jean-Luc Peurière]

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  
>> lot
>> 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  
> maintainability
> 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  
projects.
   xcode projects use shell scripts to check the cmake config have  
not changed

- 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
  own files.

- 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
nice touch

- install and bundle target (the latter for os x) are MIA (yes i  
know, wip)
- 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

Lukep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.blender.org/pipermail/bf-committers/attachments/20061030/b0a4ee44/attachment.htm