[Bf-committers] Manic MSVC blender compile session

Rene Dudfield bf-committers@blender.org
Thu, 7 Nov 2002 09:37:11 +0000 (GMT)

 --- Laurence Bourn <LBourn@medis.nl> wrote: > Hello I
had a MSVC massive blender compile session
> last night, and wow was
> it difficult to resurect this particular leviathan.
> To be honest I still
> needed a bit of help from some libraries lying
> around on my machine from NaN
> dayz.
> It would be nice to work together on this and come
> up with some tasks that
> should be done to get blender compiling on all
> plaftforms. Here are the
> things I found difficult on windows,...
> a) No extern directory yet for outside libs.
>    * I suggest we use a top level extern/platform/
> folder with lib and
> include sub directories matching the top level
> intern directories. External
> libraries that I needed were:
>     * zlib, png, openssl, fmod, openal, python
>     We should put detailed descriptions in each
> folder indicating where to
> get the libs and sources for all platforms and where
> to put them. 

Perhaps this could be a standard dir for windows.  As
on most *nix boxes people have these installed

Be good if there was one .zip or a
setup_required_blender_libs.exe.  A .exe could
download all the latest required libraries.

Probably take me a couple of hours to write one in
python.  But that adds 1.4 MB to the download.

Things like openssl, and fmod are tricky.  Why is
openssl needed?  Perhaps we could drop fmod?  Or not
include it in the dependencies as a default option?.

> b) dead directories and redundent cod. 
>   Intern contains dead or obsolete code. It is very
> difficult to work out
> exactly what blender needs so lets move the unused
> code out of there into an
> intern/attic directory or something.  
> c)Physics and sound APIs do not encapsulate external
> lib dependencies.
> Please can we move all the physics stuff into a
> seperate library (preferably
> intern) and make the library properly wrap the
> individual implementations.
> This library should not expose anything of the
> individual implementations
> outside the library. 

Nice idea, so that peoples .blend files won't break as
much with new upgrades.  But it's a lot of work. 
Maybe it would be easier to focus on one library?

> d) The same goes for the sound API it agains seems
> rather messy. Why are
> there 2 choices openal and fmod? Stick in a seperate
> independent library
> with nice API. Then write blender code to use that
> abstract API

Be good to use sdl for sound.  Lots of people allready
know the api, and it doesn't seem as dead/buggy as
openal.  Of course sdl sound doesn't do 3d sound.

Also maybe sdl could be used for input/windowing stuff
instead of ghost.  Or parts of ghost could be removed
and replaced with sdl.  Again because sdl is more
widely known.

> e) Python freeze, seems no way to perform a python
> freeze or get access to a
> libfrozen.a for windows using MSVC. Does anybody
> know how to do this?

Another part/library which needs cleaning up is the
code which uses nspr.  Some of the methods used in
blender are obsolete, and no longer work with current
nspr versions.

> Most of the simple c stuff compiled and linked
> without to many problems. 
> The last minor thing is that the .ico (icon files)
> for blender use an
> obsolete format no longer supported by MSVC.
> Anyway the final beast produced by this process
> seemed very unstable (still
> no button text on windoze builds) the thing crashed
> when I tried to do a
> boolean op (err new booleans:-) which they never did
> before.
> So what to do...
> a) Stop trying to add functionality at this stage
> (physics) 
> b) sort out and define the directory structure
> c) detail how to get external libraries for all
> plats.
> d) Sort out the fsking Makefiles and project files.
> e) Get a cross platform build tool working.

Was a decision made on a cross platform build tool? 
SirDude told me autoconf was chosen, and I think a few
others mentioned so too on irc.

If so we should start autoconfing it( note the -ph
version is mostly converted allready).  Else a
decision should be made.  I think there has been
enough discussion on this list describing the good and
bad points of each approach :)

> The project has rotted considerably (as to be
> expected) since NaN and I
> think a little discipline now would be a good thing.
> Sart cracking the whip
> Ton :-)

But not too hard!  I bruise easily.

Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts