On 05/04/2010 04:38 PM, Austin Bingham wrote:
I admit I'm having trouble formulating questions to address my problems, so please bear with me.
Say I've got a shared library of utilities for working with numpy arrays. It's intended to be used in multiple extension modules and in some places that are not modules at all (e.g. C++ programs that embed python and want to manipulate arrays directly.)
One of the headers in this library (call it 'util.h') includes arrayobject.h because, for example, it needs NPY_TYPES in some template definitions. Should this 'util.h' define PY_ARRAY_UNIQUE_SYMBOL? Or NO_IMPORT? It seems like the correct answers are 'no' and 'yes', but that means that any user of this header needs to be very aware of header inclusion order. For example, if they want to include 'arrayobject.h' for their own reasons *and* they want NO_IMPORT undefined, then they need to be sure to include 'util.h' after 'arrayobject.h'.
I still don't understand why you cannot just include the header file as is (without defining any of NO_IMPORT/PY_ARRAY_UNIQUE_SYMBOL).
From what I can see, the problem seems to be a conflation of two sets of symbols: those influenced by the PY_ARRAY_UNIQUE_SYMBOL and NO_IMPORT macros (broadly, the API functions), those that aren't (types, enums, and so forth.)
numpy headers are really messy - way too many macros, etc... Fixing it without breaking API compatibility is a lot of work, though,