[SciPy-dev] Weave: ext_module headers problems

[eric jones]

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 at scipy.net
>http://www.scipy.net/mailman/listinfo/scipy-dev
>  
>