[Bf-committers] GHOST and autoconf

Jonathan Merritt bf-committers@blender.org
Wed, 11 Jun 2003 11:15:18 +1000


Hi,

>> Could somebody with more experience perhaps comment on what the 
>> benefit is of keeping the NAN makefiles in the long run?  As far as I 
>> can tell, the main reasons seem to be that: a) there's a lot of work 
>> required to shift to GNU autotools, and b) previous NAN developers 
>> are familiar with the system.  While these are good reasons 
>> initially, I don't think they seem to be justified in the long run.  
>> (Just IMHO - there may be other reasons for keeping the NAN makefiles 
>> that I don't really understand yet.)
>
>
> c) The autotools don't seem to do such a great job on Irix or FreeBSD,
> and in particular when a non-gcc compiler is desired.


OK - fair enough.  I'm an "it works fine at my end" Linux user (with a 
highly customized box with stuff sitting in all sorts of wierd 
locations). :-)

> e) As a developer, I don't really want to learn a new system to
> recreate the Makefiles which I already have (and which I have a
> decent understanding of). I think in order to deploy the autotools
> properly you need to be both a Makefile guru and an autotools guru
> -- but if you are already a Makefile guru, why spend valuable coding
> time trying to get autotools to work?


My answer to this is: because it makes it easier for *new* developers.  
Autotools is fast and easy when it works.  If you have to learn how a 
custom build system works then this is an obstacle placed before *all* 
new developers, not just those unfortunate enough to use a system where 
autotools fails.  If, as you say, there are *many* systems on which 
autotools fails badly, then it might be not be worth adopting purely 
because developers on those systems will be so severely hampered.  
However, IMHO if a project is going to have a custom build system then 
you need to clearly place documentation about it on the website and 
provide a complete step-by-step "getting started" process for 
developers, as well as list all package dependencies, etc.  If this 
information is already online then it needs better links, and if it 
needs to be created then... I volunteer! :-)

> f) (and this is the important one) With the exception of SirDude,
> nobody seems to want to actually put in the work at getting the
> autotools system fully deployed. I know I sure don't want to... when I
> work on blender in my free time after a hard days work at the office,
> I want to work on fun computer graphics stuff rather than work on
> the build system (and I already have a build system that works, so
> I'm set to go already). I applaud SirDude's efforts... but he's only
> one guy, and unless more autotools guru's step forward and pitch in, I
> think we will remain in this limbo situation. 


Ditto to all of the above.  However, I'd like new developers *also* to 
be able to get straight at the code, for exactly the same reasons.  
Unfortunately, I'm not anywhere near an autotools guru - I just know 
it's worked well for me in the past.

> Anyways, these are a few reasons why I tend to like the NaN Makefiles
> better. I am fully willing to admit that some of my prejudices
> are based on my lack of a good working knowledge of the auto* system,
> so take them with a grain of a salt... and I hope these comments aren't
> taken too personally. My gut feeling is that in the end the autotools
> will win out (but only provided that more autotools gurus are willing
> to work on it).


I think our goals are the same.  However, if the NaN makefiles are to 
stay then they need some introductory developer documentation.  Can I 
help writing this?  Is anyone else working on it?

Jonathan Merritt.