[Bf-committers] Developers using #define in headers - how to ???

[Lukas Tönne]

I don't think there is a general method for this. In most cases it's
probably "first come, first served" ;)

Regarding the case of node IDs: This is a bit of a special case
because the node type set is changing quite often now (and will do
even more in future) - and it's supposed to! For this reason i have
been implementing a new node type registration system in my particle
nodes branch, which does not rely on static integer IDs any more.
Instead it uses identifier strings, which are much easier to keep
unique without knowing about other node systems. The main way of
comparing node types is by simple pointer comparison, similar to how
you check RNA struct types now. This makes it much easier to develop
actual independent components.

Until something like this is in trunk i guess you will have to live
with occasional ID conflicts. At least they are easy to detect and fix
:)

On Mon, Nov 7, 2011 at 6:40 PM, pete larabell <xgl.asyliax at gmail.com> wrote:
> Hey all,
>
> A recent occurrence one-again brought a question to my mind...
>
> Is there a preferred method for developers to request "safe" #define's
> in certain header files for in-development work they are doing, with
> intent that such work will eventually go into trunk?
>
> What I mean by that:
>
> Recently I submitted for review the double edge matte compositor node.
> In developing this node, I used the "next available node number" to
> represent the node.
>
> for me this was line 570 of source/blender/blenkernel/BKE_node.h
>
> I had used:
>
> #define CMP_NODE_DBLEDGMATTE    262
>
> and a recent merge (which I'm certainly happy to see :) ) added:
>
> #define CMP_NODE_MOVIECLIP      262
> #define CMP_NODE_STABILIZE2D    263
> #define CMP_NODE_TRANSFORM      264
> #define CMP_NODE_MOVIEDISTORTION        265
>
> which of course caused conflict.  Not a big deal, since it's a quick
> fix in only one file for me, but it raised the question again in my
> head:
>
> Is there something already in place (possibly it's currently just "ask
> on #blendercoders" which I supposed would have worked) where devs
> could keep a running list of what eachother are doing in certain files
> which require unique numbers so as to not overlap numbers like I did?
>
> Again I'm certainly not complaining, and as stated this is incredibly
> easy to fix, but in my case, and possibly due to my own negligence, I
> had already submitted a patch for review before discovering this
> overlap.
>
> I know it could get messy if we have a "developers reservation list"
> where people could go reserve arbitrary amounts of #define s for
> projects, some of which may never see the light of day.
>
> So all that being said: Is there some way for people like me to avoid
> duplication such as this in the future? Or is it best to just ask in
> IRC?
>
> Cheers!
> Peter
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>