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

[Jacques Beaurain]

Hi Joseph,

Thanks for the feedback, some replies below....

On 9/18/06, Gilbert, Joseph T. <jgilbert at tigr.org> wrote:
> 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
....
> 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.
>
To reiterate on Chris's response. You can generate the project files
and objects in a different directory by running the generator in that
folder. The example I used so far was to create the follwing directory
(relation shown to blender sources):

.\blender
.\lib
.\cmake-build

And then in cmake-build to run:

cmake -G cmake -G "Visual Studio 8 2005" ..\blender

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

I have mixed feelings about this one; one of the major problems I've
had with the current MSVC project files was the extern/intern/src
separation. Having it all in one solution keeps things simple (the
dependencies are correctly set up BTW), when somebody updated
something in extern (e.g. verse) and you do a CVS update linking or
compiles may start to fail if you are just working in src. Also, the
IDE will keep track of changes for you and only rebuild stuff if the
sources or headers changed that affects it. One thing I think that
could be done is to name the libraries better (e.g extern_..
intern_... blender_.. player_... core_...), I kept the Scons naming
for now. Any comments on this?

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

I did not know that I include the ActiveX controller? This sounds
strange, also the targets can be built (under MSVC) depending on which
target you select in the IDE:

1. Debug
2. Release
3. MinSizRel
4. RelWithDebInfo

It is forcing you to rebuild something you already built, are you sure
you did not open the MSVC solutions in CVS?

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

Because there is more than one executable in the solution MSVC does
not set a startup project. You can do so by using RMB->"Set as startup
project" for the blender project.

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

TODO : Postbuild step for doing this as well as possibly create a
CPack installer target (
http://www.cmake.org/Wiki/CMake:Packaging_With_CPack )

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

TODO: See 6

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

TODO: See 6&7 I will make a postbuild step that copies all to
../cmake-install for packaging.


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

Cheers,
Jacques