[Bf-committers] GHOST and autoconf

[Kent Mein]

In reply to Douglas Bischoff (bischofftep@mac.com):

> Hello:
> 
> Still pushing towards an eventual decision on whether autoconf or NAN 
> makefiles are the "true way to Blender compilation," I have a question 
> or three.
> 
> 1) When building using the NaN makefiles, I gather that the program is 
> linked against libraries present in the "lib" directory.

Its linked to where ever you set the NAN_GHOST env var to...
(actually there are all kinds of NAN_blah env vars that get used)

> 
> 2) If this is true, is there a similar mechanism for the autoconf 
> system? For example, GHOST. Without merging the GHOST tree with the 
> Blender tree, how can one obtain a stable GHOST library and get it to 
> link to the autoconf-built Blender?

Working on it, first goal though is a stand alone version of ghost which
I've been spending my time on.  The Current Todo list for a GHOST release
is basically finishing up an alternate generic Makefile for ghost
(Need to finish up the building of the test files and the documentation with it)
and documentation for alternate build systems (project files and project builder)

Once thats done and released I'm going to work on making it so autoconf will
work with stand alone ghost.
  
> 3) All the talk of creating a .blender directory and moving the files 
> necessary for international support, etc. are great... is ANYONE 
> working on this functionality for autoconf?
> 

I sent LarsitQ the start of setting this up for autoconf not sure if he
has made any progress on this or not.

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


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.

Kent
-- 
mein@cs.umn.edu
http://www.cs.umn.edu/~mein