> 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4