[Bf-committers] GHOST and autoconf

Hans Lambermont bf-committers@blender.org
Mon, 9 Jun 2003 21:10:49 +0200


Kent Mein wrote:

> In reply to Douglas Bischoff (bischofftep@mac.com):
> > I really don't object to NaN makefiles, but I just want to know if, as 
> > someone hoping to learn enough to contribute someday, I should forget 
> > autoconf and focus on NaN makefiles, or if it is okay to keep using 
> > autoconf because someday it will be "the way."
> 
> I think I've said this before, and its only my opinion but I personally
> would like to see both systems around for as long as possible.  (As well
> as the Microsoft and the project builder way of doing things)
> As long as we can keep them all up to date, its nice to have options.
> That way if someone isn't comfortable with dealing with autoconf they
> can use the NAN Makefiles if they want.  (and the other way around of course)
> Also there may be bugs introduced in one build system that only affect one
> platform.  If there is an alternate build system then development won't
> stop on that platform until "the" build system gets fixed.

Great idea, but it'll cost lots of resources. At NaN we struggled with
the makefiles vs. windows project files. Some ppl generate the windows
project files from makefiles as well, but we never tried it.

> One other thing I have on the to do list is to move the NAN Makefiles to
> something like Makefile.nan so that they don't get overwritten by autoconf
> and both can live in harmony.

Do you imply that the auto* system will generate makefiles *in* the
source tree ? I hope you're not, it'll confuse ppl, generated things
will accidentally get comitted etc. Bad Idea (tm) IMO.

Hans

ps.  Would it be beneficial if I'd change the NaN system such that the
$NANBLENDERHOME is made relative to each Makefile and thus be
unneccesary ? This way NANBLENDERHOME and MAKEFLAGS can be removed. It
confused a lot of ppl :-/
-- 
http://lambermont.webhop.org/   () ascii ribbon campaign - against HTML mail,
                                /\ vCards and proprietary formats