[Distutils] People want CPAN

[Tarek Ziadé]

On Wed, Nov 11, 2009 at 11:49 PM, Pauli Virtanen <pav at iki.fi> wrote:
[..]
>
> Just to throw some wild, perhaps obvious, and definitely unasked-for
> ideas in the air (especially as I can't promise I can give any sustained
> help here :/ ):
>
> I suppose one option would be to factor *everything* related to
> extension module building into build_ext (and abolish build_clib): the
> rest of distutils would just say to build_ext
>
>        """
>        Here's some info about the environment:
>
>        dict(python_lib_path=/usr/lib/..., optimize=yes/no,
>             python_lib_name=..., python_includes=/usr/include/...,
>             install_prefix=/usr/lib/python2.6, ...
>             ..., python_extension=..., build_temp_dir=...)
>
>        Look the rest up from sysconfig.
>
>        Please build any extensions and data files you like,
>        and tell the file and directory names where you placed them
>        and where (relative paths) they should go.
>        """

I ought to be something like that, but what is unclear to me is how to
describe which compiler to use for what files.

I had this "one extension == one compiler type" pattern in my head,
but it seems more complex than that. IOW an extension can invoke
several compilers and tools to be built.

So "one extension == one extension builder" might best describe it.
and I am wondering
if we can't define a simple interface for these extension builders,
from the simplest case (one tool uses one compiler) to the weirdest
one (one tool uses a complex toolchain to create the extension)

So at the end we would have:

- Extension (the existing extension class, that takes a
"extension_builder_type")
- ExtensionBuilder (class in charge of creating an extension)
- a registery for ExtensionBuilder subclasses

And have the community create new ExtensionBuilder subclasses that
could be registered like command.

build_ext would then become an empty shell, just in charge of looping
through the extensions,
so each extension invokes its builder.


[..]
> I think this idea quickly boils down more or less to David's idea about
> a pluggable build system -- implementing a good one takes a lot of work,
> so it might make sense to refactor distutils so that it would be
> possible [1] to use some of the existing ones (scons, waf, whatever,
> heck, even autoconf+make). The *default* build system could be a simple
> one, and backwards compatible. Especially so, since it seems to me that
> building extension modules is orthogonal to what distutils and
> setuptools want to do -- package and install Python modules in a
> Python-specific way, not really worry about how to properly call
> different compilers on obscure platforms.
>
> Anyway, even in the case pluggability is a bad idea, refactoring the
> build system out from the rest of distutils might make sense.

Agreed. it seems that the addition of the "configure" command, and the
refactoring
of the "build_ext" one, are the right things to do, together with the addition
of the "sysconfig" stdlib module (which allows configure to get more info that
what distutils.sysconfig provides)

Now, if we can take back the work done in 4suite as suggested, or in scons, etc,
that's even better.


Tarek