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

[Gilbert, Joseph T.]

First of all I'd like to say thx for working on such a complex build
system.
I have built the VC2003 7.1 blender from Cmake (the IDE 7.1 not the free
version). I had no problems with the build (including the resource icon
issue mentioned earlier). However there are a few areas that need to be
addressed:

1- The source tree is a mess. Cmake throws files and directories all
over the blender/source tree like a wild kid. Even from the time of the
obj/ directory there has been an effort to keep the "crap" out of the
source tree. (other than makefiles). Both Scons and the vc7/vc8 project
files put all the linker intermediate files in a separate directory tree
called build/xxx, where xxx = the build type. vc7 uses the build/msvc_7
directory to store .obj files for instance. 
If I want to delete that 1-2gigs of .obj files, I have to search through
the source tree now (or delete the whole things and do and update from
cvs).  Notice that the vc7/vc6 projectfiles reside in their own tree
structures rather than living inside the source tree (as is the usual
Microsoft custom).
There is a 1) buildfile directory 2) a sourcefile directory 3) a build
output directory. 

2- Libraries and source are mixed in the build.  The extern/ and intern/
libraries are being built with the source/ tree. This is nice the first
time you build blender. However, once you build extern/ and intern/
there should really be no need to build them again unless your are
working on one of blender's dependances. 
Intern/ and extern/ can be built together, but no alongside the source/.
For developers it's a pain.
(ALLBUILD and INSTALL aren't really necessary if you supply the correct
dependancies for each module and use the post-build events, although its
not a big deal.)

3- Blenderplayer, Blender, and the activeX controller are all being
built under 'release'.  These should be built under different builds. I
never build the activeX controller and should not be forced to everytime
I recompile.

4- Under the debug build I'm getting "please locate the executable to
use for the debug build" and a search box. This is very unusual for
msvc. It seems that the project doesn't know where the executable when
to.

6- None of the builds are putting the proper .dlls in the executable
bin. Python24.dll, etc. are not being copied out. This means when you
click the executable after the first build you'll simply get a error
message requesting the the location of the external dependancies. Either
the dependancies need to be on the system path (or more common for
windows) they need to be in the .exe's directory path. 

7- Scripts and .po's are not being creating in the executable bin. There
is no .blender directory for launching the default config file. There is
no release info being copied out.

8 - I also had trouble finding where blender.exe when to. It not in the
bin/ directory as one would expect but in the ../cmake-build/bin
directory. This really should be send to blender/bin/.

Anyway, just a few comments on what I saw for the vc7 build.  Thanks for
the hard work btw on this system.

Joseph (ascotan)

-----Original Message-----
From: bf-committers-bounces at projects.blender.org
[mailto:bf-committers-bounces at projects.blender.org] On Behalf Of Jacques
Beaurain
Sent: Monday, September 18, 2006 6:56 AM
To: bf-blender developers
Subject: Re: [Bf-committers] Re: handcrafted makefiles, autotools,scons
and cmake ?

Hi Chris,

Thanks for the feedback, some replies below:

On 9/17/06, Chris Want <cwant at ualberta.ca> wrote:
> be an important gauge of cmake's usefulness. Also, I'm not sure
> how difficult this system is to maintain (for example, can a
> person just add a C file to a directory and expect it to
> build, or do they have to name each file somewhere?).
>
Currently the system is modelled after the Scons system, so in places
where wildcards for sources were used I used wildcards and in places
where it was not I didn't. In most places though wildcards are used,
so if a person runs cmake generation directly after doing a get the
projects and makefiles should be correct, so this has to be added to
the developer's workflow that plans to make use of this system.

>
> * in the tar file there is extern/verse/dist/mkprot/CMakeLists.txt,
> but sometime during my previous build with make there was a
> file created called extern/verse/dist/mkprot, and this caused
> the extraction of the tarball to fail.

I have been using a clean source tree every time, so have not run into
this, but I also do not use the make system. Is this not a problem
with the verse makefiles writing output directly into the sources
instead of the build directory? I will change the folder name for the
mkprot subdir to not interfere with the make system if people use both
for some reason.

>
> * my build fails because there is no option to exclude openal
> and I don't have openal installed
>

I tried to minimize the number of options available to simplify things
for the developers, so I used autodetection cmake scripts where
available. OpenAL is supposed to be turned off automatically if not
detected. What platform are you using? I will fix this or add an
option back.

One other question; OpenAL and SDL does not seem to be mutually
exclusive in blender build, if there is an option it could just be
WITH_SOUND which will require both libraries right?

> * I use the nice 'ccmake' tool for a curses interface to
> configure the sources. Each time I press 'c' to configure,
> I get a warning that essentially says:
>
> CMake produced the following output:
>
>   Configuring library bf_soundsystem
> .
> .
> etc.
>
> My guess is that you aren't handling output (like stdio/stderr)
> correctly in your cmake files. Other projects that use cmake
> (e.g. VTK) don't give such messages.
>

I have been using the command line interface and used the MESSAGE
command to output the configuration stage. It does however give some
progress feedback for command line usage, I will change the message
types to STATUS all over, which will give feedback in the status bar
instead in the UI.

Cheers,
Jacques
_______________________________________________
Bf-committers mailing list
Bf-committers at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-committers