[ZODB-Dev] BTreeModuleTemplate.c inflexibility

[Tim Peters]

[Martijn Faassen]
> I maintain a long long using BTree in my own source tree now, and it is
> *almost* enough to just implement very simple .c files _LIBTree.c and
> _LOBTree.c, as well as a special template .c file called llkeymacros.
>
> Unfortunately when pickling I do run into an issue.
> BTreeModuleTemplate.c defines a MODULE_NAME which is set to
> "zodb.btrees.".

No, it's defined like so:

#define MODULE_NAME "zodb.btrees." MOD_NAME_PREFIX "BTree."

MODULE_NAME expands to things like

    "zodb.btrees.OOBTree."
and
    "zodb.btrees.IOBTree."

due to preprocessor string catenation, depending on how MOD_NAME_PREFIX is
defined.

> Since my own BTree variants are stored somewhere else pickle starts to
> complain.

Understood.

> If I had the ability to define MODULE_NAME in my own  _LIBTree.c etc
> this problem would go away, and I didn't need to include my own version
> of BTreeModuleTemplate.c anymore.
>
> So I suggest we change the code in BTreeModuleTemplate.c along
> the following lines, from this:
>
> #define MODULE_NAME "forest." MOD_NAME_PREFIX "BTree."
>
> To this:
>
> #ifndef MODULE_NAME
> #define MODULE_NAME "zodb.btree.s"
> #endif
> #define MOD_NAME_PREFIX "Btree."

I assume there's at least one typo there, and possibly several:
MOD_NAME_PREFIX is currently defined in 5 different files (one for each
existing flavor of BTree), and you can't go unconditionally stomping on it.

> That would allow me to set my own MODULE_NAME.
>
> (note that I'm talking about the version of ZODB in the latest
> Zope3 checkout here)

Me too.

I have no objection to this, provided that:

a) It doesn't break what's already there.

b) You document the intended use of MODULE_NAME in Maintainer.txt.
   It's not documented now because it's effectively an unalterable
   constant now.  But if you switch it to a parameterizable thing,
   then without docs the intent is a mystery and so will certainly
   either break, or just get deleted again, later (I routinely delete
   decoys in the BTree code, whenever I figure out that some
   preprocessor obscurity is unused).