Page MenuHome

Basic support for #define in makesdna
Closed, ArchivedPublicTO DO


Here is a patch that brings basic support for #define's in makesdna - I say
basic, because there are some limitations:

* Only "full numeric" #define are processed:
#define OK_VALUE 32 /* is ok: only digits */
#define KO_VALUE 1024*4 /* is wrong: character other than digit */
#define KO_VALUE2 OK_VALUE /* is wrong: ref. to other define not allowed */

* define's are only replaced in array definitions
#define ARRAY_SIZE 32
struct mystruct {
char myarray[ARRAY_SIZE]; /* will be replaced with "char myarray[32]"

* multiple #define of the same tag with different values drops the tag:

if you have in one file:
#define MY_TAG 32
then later (in same file or in other one)
#define MY_TAG 64
then the value of MY_TAG is marked invalid and MY_TAG will not be replaced

* #ifdef and #undef are not taken into account, so something like the following
will result in MY_TAG being marked invalid (this should not harm a lot, as
array sizes in DNA should not depend of any #ifdef...)

#define MY_TAG 32
#define MY_TAG 64 /* MY_TAG seen twice with different values => invalid */

- or -

#define MY_TAG 32
#ifdef MY_TAG
#undef MY_TAG
#define MY_TAG 64 /* MY_TAG seen twice with different values => invalid */

I also added a test in makesdna to check that array size are >= 0, and make the
program fail if this is not the case... This to prevent something like the
following not being detected by makesdna and producing zero length array...
char array1[UNKNOWN_TAG]; /* UNKNOWN_TAG not being defined / invalid */
char array2[16*2];

For now I only modified VS2003 project (I dont think Scons needs any change),
and tested under Windows (MSVC only, as I failed to build with Scons under
mingw - I'm checking my configuration as I never had any problem with 2.43).

I only added a few #define, for "proof of concept":
NAME_SZ in struct ID (field name)
NAME_SZ in struct Sequence (field name)
FILE_MAX in struct Library (fields name & filename)
FILE_MAXFILE in struct StripElem (field name)
FILE_MAXDIR in struct Strip (field dir)

... and could removed the double definitions of FILE_MAXDIR, FILE_MAXFILE and FILE_MAX from DNA_space_types.h and BKE_utildefines.h (moved them to new file

My ultimate goal is to be able to increase the size of ID's in Blender
(21 chars is a bit short). This could also make the code easier to read, if
one see something like NAME_SZ instead of integer values like 24 or 21...


I know this is not perfect; I wanted to use the preprocessor to handle all that
stuff in a clean way:

* create a new file DNA_prepro.c, which just includes all DNA_*.h files
* preprocess DNA_prepro.c (with all project flags) to obtain a DNA_prepro.i file
* change "char *includefiles[]" array in makesdna.c so that it contains only
DNA_prepro.i (and only #include "DNA_prepro.i" at end of makesna.c file)
* ... and let all the code in makesdna.c just the way it is now (except for
testing array sizes).

I know how to do this whith make (and I thing I can deal with Scons too, with
some reading/googleing) but my main concern is MSCV projects; I was not able to
make a "preprocess only" project in Visual Studio 2003 (I find a way in VS2005,
by making an ".exe" project, and preventing the linker to launch, but I don't
know how to do the same in VS2003).

So I rolled back to my "second solution" that I presented here...

Event Timeline

Nobody (None) changed the task status from Unknown Status to Unknown Status.Dec 8 2007, 8:37 PM

Patch is working fine with Scons (Windows, using mingw) with no addtional modification.

It seems there's a problem building Blender with latest version of Scons (scons-0.97.0d20070918); I had to revert back to scons-0.96.96 .

Blender should build with the latest stable. That version number leads me to believe that's an intermediate release. Anyway,could you paste the errors you get when building with that version?


Here is the log file of building with scons-0.97.0d20070918

Official Blender 2.45 release, default options (no


For the time being I won't accept any improvements in this code. We're going to see a major recode in core areas of Blender that will give enough issues already.
Will assign to self for later evaluation after we've survived 2.5. Hope you understand... (btw, longer names than 21 chars I'd like to tackle myself). Thanks!