[Python-Dev] Looking for a DL_xxPORT macro export

[Mark Hammond]

> This is your basic Undocumented X-Platform Macro Hell, and I suppose the
> Windows build should be #define'ing USE_DL_EXPORT for these subprojects
> anyway (?), but if I don't hear a good reason for *why* both
> macros are used

This is a mess that should be cleaned up.

I take some blame for DL_IMPORT :-(  Originally (and still, as far as I can
tell), DL_IMPORT really means "Python symbol visible outside the core" -
ie, any symbol a dynamic module or embedded application may ever need
(documented, or not :-)

The "import" part of DL_IMPORT is supposed to be from the _clients_ POV.
These apps/extensions are importing these definitions.

This is clearly a poor choice of names, IMO, as the macro USE_DL_EXPORT
changes the meaning from import to export, which is clearly confusing.


DL_EXPORT, on the other hand, seems to have grown while I wasnt looking :-)
As far as I can tell:
* It is used in ways where the implication is clearly "export this symbol
always".
* It is used for extension modules, whether they are builtin or not (eg,
"array" etc use it.
* It behaves differently under Windows than under BeOS, at least.  BeOS
unconditionally defines it as an exported symbol.  Windows only defines it
when building the core.  Extension modules attempting to use this macro to
export them do not work - eg, "winsound.c" uses DL_EXPORT, but is still
forced to add "export:initwinsound" to the linker to get the symbol public.

The ironic thing is, that in Windows at least, DL_EXPORT is working the
exact opposite of how we want it - when it is used for functions built into
the core (eg, builting modules), these symbols do _not_ need to be
exported, but where it is used on extension modules, it fails to make them
public.

So, as you guessed, we have the situation that we have 2 macros that given
their names, are completely misleading :-(

I think that we should make the following change (carefully, of course :-)

* DL_IMPORT -> PYTHON_API
* DL_EXPORT -> PYTHON_MODULE_INIT.

Obviously, the names are up for grabs, but we should change the macros to
what they really _mean_, and getting the correct behaviour shouldn't be a
problem.  I don't see any real cross-platform issues, as long as the macro
reflects what it actually means!

Shall I check in the large number of files affected now?

Over-the-release-manager's-dead-body<wink> ly,

Mark.