MSVC6
Defensive way not to interfere with other (crystal) build systems
so .. i can maintain building bullet for blender on MSVC6 without spitting in
the "whateverbulletteamthinkstobenice" soup
no GE right now ( need to adapt to erwins file reshuffle
so may be i wait a bit until he has his mind made up )
elbeem is running when you remove the extra std:: at some places
well the msvc6 preprocessor is not very smart
--> std:: is not a member of std:: :)
so i guess there is a "using namespace std" somewhere
NOTE to Ton and Hos
PLEASE do not try to merge any ot the MSVC6 project files (*.dsw ,*dsp)
I have a plan to get it done with a minimum of pain
thanks
ole
post build step for booleans --> copy boolop.lib to lib folder _foo_/lib/windows..
enabeling bullet for GE
wants to link with _foo_/lib/windows/bullet/lib/bullet3.lib
you have to build it with continuous.dsw in exten/bullet and copy it manually there
since bullet is exten i think no automagic in place here
So the linker only misses performElbeemSimulation(..)
I can't create El'Beem.lib with msvc6 as discussed in ML
If you comment off the 2 calls in fluidsim.c
blender compiles with msvc6 projects again
with the complete fluid UI but simulation won't run
BPY_python.dsp need some changes too (adding Font.c and Font.h) but I've got other changes in there that I can't commit, so someone else will have to update.
fixed some *includes*
with
#ifdef WIN32
#elif
#include <sys/time.h>
#endif
looks like MSVC6 does not need that include .. donno if cygwin builds will
so thats why i kept that *ifdef overhead*
MSVC 6.0 Projectfile changes for zblur and new files in ketsji.
Also adding BL_src projectfile to the commit, apparently it's not up to date with transform_conversions.c but I have it ok here and don't get any diffs.
Split the conversion fonctions and sorting functions from transform.c into transform_conversions.c
Update MSVC 6.0 projectiles and SConscript accordingly.
Editview still included transform.h, replaced that for BIF_transform.h, the external include.
