[Distutils] People want CPAN

Tarek Ziadé ziade.tarek at gmail.com
Wed Nov 11 21:42:32 CET 2009

On Wed, Nov 11, 2009 at 9:22 PM, Pauli Virtanen <pav at iki.fi> wrote:
> ke, 2009-11-11 kello 16:47 +0100, Tarek Ziadé kirjoitti:
> [clip]
>> >> If it's the later, I guess you will be able to use the
>> >> upcoming "sysconfig" module,
>> >> that gives you the install schemes, depending on sys.prefix/sys.exec_prefix.
>> >
>> > Where is the sysconfig sources ? I don't see it in bitbucket.
>> That's in python's svn, in a tarek_sysconfig branch. It's a revamp of
>> distutils/sysconfig.py with the schemes from distutils/command/install.py
>> (work in progress)
> What if the user passes a different install prefix via
>        python setup.py install --prefix=FOO
> I believe David would like to know FOO here. Since sysconf is not a part
> of distutils, will it know what FOO is?

I am not sure he wants FOO, I think he wants all installation paths,
that gets built
by the install command with the provided "FOO" root prefix.

that could be in pseudo code:

>>> get_install_paths('FOO')

And that's the API we want to add in sysconfig, roughly.

> I think one question here is that how do the different compilers speak
> to each other?
> Consider the following chain needed to compile a Cython file linking to
> some Fortran and C files to a Python module:
> - cython foo.pyx -> foo.c
> - compile foo.c -> foo.o
> - compile bar.c -> bar.o
> - compile quux.f90 -> quux.o
> - link foo.o bar.o quux.o -> foo.so
> This is a completely possible use-case, so it would be good if distutils
> could handle it. Also, dependency handling would be nice here. Changing
> bar.c or foo.pyx should trigger relinking foo.so etc.
>> So, yes, being able to register an arbitrary compiler class, with
>> arbitrary options passed through the Extension
>> could make it simpler:
>> setup(
>> ..
>> ext_modules=[Extension('Foo', files=['foo.d'], compiler='pyd')],
>> ..)
> Does this work easily out when there are multiple source files (in
> different languages) for a single extension module?

Do you mean, an Extension that would require several compilers ?

I was thinking of a one-to-one relation between an Extension and a
compiler type,
even if there are are multiple source files (in different languages)
for this extension.

Meaning that *one* compiler would have to handle of those files. Does that fit
the cython use case ?

> Also, the option of determining the necessary compiler and compiler
> options from file extensions does not always work. For example, Fortran
> 90 files come in two flavors, fixed-form and free-form, which often are
> not differentiated by the file extension. However, they may require
> different compiler flags to compile. (Hopefully, however, nobody uses
> the fixed-form for F90 any more...)

How do they do then ? Is file extensions, inline options in setup.py,
and the environ, are enough ?


More information about the Distutils-SIG mailing list