I just made some (really quick) tests with cpp (gcc's preprocessor), and with the -P -D DNA_DEPRECATED_ALLOW options, generated files seem to work just fine with makesdna.
The drawback of preprocessing is that it does the includes, so a few structs are defined in every DNA_foo.h preprocessed file – but I don't think this is a real problem, it just adds a (really small) overhead to the building process. So if we can get a similar result with msvc, we could just add an additional build step to generate those preprocessed DNA files, before running makesdna – and enjoy a full preprocessing for dna files… Le samedi 17 décembre 2011 18:18:56, Bastien Montagne a écrit : > About makesdna not being able of interpreting #defines, why not simply > use a C preprocessor over all DNA_foo.h files, before giving them to > makesdna ? GCC, MSVC, etc. already have coded that, why trying to > re-implement a (highly limited) version for makesdna… > > Just an idea, maybe I’m again missing something important! ;) > > Le jeudi 15 décembre 2011 16:39:06, Bastien Montagne a écrit : >> Ah, so this is the why of this situation… I see the situation is even >> more complex than what I thought. Ugly dummy DNA! :P >> >> Le jeudi 15 décembre 2011 14:20:58, Christian Monfort a écrit : >>> Hi, >>> >>> I don't know if Joshua is talking about the patch I made some years ago for >>> Blender 2.45... >>> Anyway, it is now in the "Todo": >>> http://projects.blender.org/tracker/?group_id=9&atid=264&func=detail&aid=7889 >>> >>> Christian >>> >>> Le 15 décembre 2011 12:55, Brecht Van Lommel<[email protected]> >>> a >>> écrit : >>> >>>> I think such defines should be used ideally, but the reason they are >>>> not used in DNA_* structs is that makesdna can't parse them. >>>> >>>> Brecht. >>>> >>>> On Thu, Dec 15, 2011 at 12:27 PM, Bastien Montagne >>>> <[email protected]> wrote: >>>>> Hi devs! >>>>> >>>>> While working on some improvements to WeightVG modifiers, I stumbled >>>>> upon that: in DNA def of modifier structs, all vgroup and uvmap name >>>>> lengths are literal (32)… Imho, a define would be much better (and much >>>>> easier in case we decide to change it one day). We do have a >>>>> MAX_VGROUP_NAME defined in DNA_object_types.h – but I guess including >>>>> that file into DNA_modifier_types.h just for that wouldn’t be wise. >>>>> Also, the FILE_MAX& co are defined twice, once in BKE, once in DNA… >>>>> >>>>> So here is my proposition: why not gather all those string-length >>>>> defines in one place (e.g. the recent DNA_defs.h, which seems to be >>>>> safely includeable every where) ? After a quick search, this would >>>>> concern at least: >>>>> * FILE_MAX and co >>>>> * MAX_VGROUP_NAME, MAX_STYLE_NAME, MAX_FONT_NAME (and others, like [new] >>>>> MAX_OBJ_NAME, MAX_UVMAP_NAME, etc.) >>>>> * MAX_ID_NAME and MAX_IDPROP_NAME >>>>> >>>>> Also, would we need a MAX_VGROUP_NAME, MAX_OBJ_NAME, MAX_UVMAP_NAME, >>>>> etc., or just define a common MAX_BLDEF_NAME (e.g.), as they all seem >>>>> set to 32 currently? >>>>> >>>>> I’m well aware that this involves many parts of Blender code, and as >>>>> such might need a much deeper knowledge of that code than I currently >>>>> have (even though changes could be made progressively, as values would >>>>> remain the same) – but I really think this should be addressed, for >>>>> sanity of code. >>>>> >>>>> Best regards, >>>>> Bastien. >>>>> _______________________________________________ >>>>> Bf-committers mailing list >>>>> [email protected] >>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>> _______________________________________________ >>>> Bf-committers mailing list >>>> [email protected] >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>> >>> _______________________________________________ >>> Bf-committers mailing list >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> >> >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
