[SciPy-dev] Re: Another issue with scipy_distutils and FORTRAN files

[Berthold Höllmann]

Pearu Peterson <pearu at scipy.org> writes:

> Hi Berthold,
>
> On Tue, 30 Mar 2004, [ISO-8859-15] Berthold Höllmann wrote:
>
>> It turned out, the problem is how to tell include directiories when
>> generating a library. We use
>> 
>> ---snip---
>> ...
>> flibs = [('fortmisc',
>>           {'sources': lib_src,
>>            'include_dirs': [os.path.join("lib", "numfort")],
>>            'macros':[]},),]
>> ...
>> setup(...
>>       libraries=flibs,
>>       ...)
>> ...
>> ---snip---
>
> This usage of specifying libraries is not recommended and some of the
> corresponding features were removed indentionally (but at the moment I am
> not sure why the above does not work..), though the standard distutils
> might support this. The reason comes from the experience of building 
> scipy: the above approach would cause 'fortmisc' to be linked with 
> all extension modules that a package contains and this may cause undesired 
> effects, for example, when subpackages define different libriaries 
> with the same name, etc. The recommended way of specifying libriaries is 
> to add them explicitely to extension modules that actually need them:
>
>   flibs = [('fortmisc', {'sources': ..., 'include_dirs': ...})]
>
>   ext = Extension('extname',
>                    ...
>                    libraires = [..]+flibs,
>                    ...)
>
>   setup(...,
>         ext_modules = [ext,..],
>         ...)

That is OK for me, I did not know this is possible. But to my
experience the 'libraries' argument to 'setup' only tells distutils
what libraries to build, if you want to link it to a specific extension you
also have to give it's name in the 'Extension(...libraires' option. I
have at least one library that is shared amongst some extensions. It
is a dummy library to make distutils use the FORTRAN compiler for
linking the extension because although all code belonging to the
extension is C code, some of the external libraries used are FORTRAN
code, and it is much easier to use FORTRAN compiler to link C code
than the other way round (at least in my experience).

>
>> I guess the the correct fix lies in _compiler in fcompiler.py. The line
>> 
>> ---snip---
>>         command = compiler + cc_args + s_args + o_args + extra_postargs
>> ---snip---
>> 
>> should be
>> 
>> ---snip---
>>         command = compiler + cc_args + s_args + o_args + extra_postargs + pp_opts
>> ---snip---
>> 
>> (at least this works for me). 
>
> Let me know if the above approach of specifying libraires is acceptable 
> for your application and then I'll postpone tracking down the "correct" 
> fix to the problem. I am just hesitating commiting patches that I don't 
> understand fully.. pp_opts should probably used only as preprocessor 
> arguments but scipy_distutils does not have preprocessor support
> yet.

There is usually some "internal" preprocessing support in FORTRAN
code: using the 'include "some.inp"' command. Some FORTRAN compiler
such as Compaq or SunFortran are looking into the direcory where the
source file comes from for those include file, but unfortunately the
Intel Compiler (at least under Linux) does not. So even without real
preprocessing support at least the 'include_dirs' part of 'pp_opts' is
needed for the FORTRAN compiler. For the four FORTRAN compiler I have
access to, using the preprocessor is just another compiler option:

   g77: -x f77-cpp-input
   ifc: -fpp
   Sun: -fpp
   compaq: /fpp

So maybe implemention is easy?

'_compile' gets only pp_opts as an argument so I used it in building
the command line, but of course one could split 'pp_opts' again in
'macros', and 'include_dirs' and give those to _compile.

>
>> Of course "NB.F" only compiles with
>> another (helpfull) patch to fcompiler.f. I changed 
>> 
>> ---snip---
>>     language_map = {'.f':'f77',
>>                     '.for':'f77',
>>                     '.F':'f77',
>>                     '.ftn':'f77',
>>                     '.f77':'f77',
>>                     '.f90':'f90',
>>                     '.F90':'f90',
>>                     '.f95':'f90'}
>> ---snip---
>> 
>> and
>> 
>> ---snip---
>>     src_extensions = ['.for','.ftn','.f77','.f','.f90','.f95','.F','.F90']
>> ---snip---
>
> This is now in CVS.
>
>> Probably 'language_map' shold reflect that '.F' and '.F90' files
>> should be preprocessed using fpp, and fpp must be explicitly switche
>> on on some platforms.
>
> Yes, I agree.
>
> Thanks,
> Pearu

Thanks,
Berthold
-- 
Germanischer Lloyd AG
CAE Development
Vorsetzen 35
20459 Hamburg
Phone: +49(0)40 36149-7374
Fax: +49(0)40 36149-7320
e-mail: hoel at gl-group.com
Internet: http://www.gl-group.com 
 
 
 
This e-mail contains confidential information for the exclusive attention of the intended addressee. Any access of third parties to this e-mail is unauthorised. Any use of this e-mail by unintended recipients such as copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this e-mail is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this e-mail.  
 
GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc.