+1 That was my 1st idea, but keep in mind that preprocessing does not solve all cases:
#define STR_SIZE 32 char* s1[STR_SIZE]; char* s2[STR_SIZE*2]; char *s3[STR_SIZE+2]; will preprocess to: char* s1[32]; char* s2[32*2]; char *s3[32 +2]; which was not handled by makesdna (at least the last time I worked on this, that is Blender 2.4x) for s2 and s3. Le 17 décembre 2011 20:16, Bastien Montagne <[email protected]> a écrit : > 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 > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
