Hey Prabhu, I have some memory of the order being important for another code section (like support_code), but I can't concoct an example that breaks off hand. There isn't a unit test that exercises this. It is reasonable to expect Python.h to always be the first include -- except for the special case of blitz.h always needing to be first in a file which is special-cased in the weave code generation (gotta love that...). It is OK to check in the change. If we find an example it breaks in the future, we will need to find an approach that gets all the code sections assembled in the correct order. eric Prabhu Ramachandran wrote:

Hi,

This question is mostly for Eric. In ext_tools.ext_module this is the definition of build_information:

def build_information(self): info = [self.customize] + self._build_information + \ self.arg_specs().build_information() # ...

This means that any headers added via

ext_module.customize.add_header('foo')

are added *before* Python.h and this triggers warnings when the functions are compiled. This is also what is invoked for all weave.inline calls (see inline_tools.py line 433).

To get around this I've changed the definition to:

def build_information(self): info = self._build_information + [self.customize] +\ self.arg_specs().build_information() # ...

This fixes the warnings and puts the user headers last. I am not sure there is any specific reason that you put self.customize first. I just thought I'd check with you before checking the change into CVS.

Thanks.

cheers, prabhu

_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev