[Bf-committers] Proposal: rationalize string-length #defines

[Bastien Montagne]

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<brechtvanlommel at pandora.be>    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
>>>> <montagne29 at wanadoo.fr>    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
>>>>> Bf-committers at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>>
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers