[Distutils] People want CPAN

[David Cournapeau]

On Wed, Nov 11, 2009 at 10:16 PM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:

>
> Ouch, That's not to be done. Something is wrong with your build_clib
> design here.
> You are roughly calling "install" as a sub command.

Yes, it is "wrong" from distutils POV, but there is no other solution
to get the prefix. The problem is that prefix is available in install,
not that I want to know the prefix when building.

>
> If you want to have install options for your command, and if your
> command is about "installing",

I did not say my command was about installing - it does not install
anything. To be complete, we do not use this in build_clib, but in
build_src , to generate pkg-config-like files (build_src is a
numpy.distutils-specific command to build source files, for example
automatically generated wrappers around fortran libraries, and is
typically run before any other build_ command)

>
> For build_clib, if you need to build something, it goes in the
> build_dir, or in place., and this is not impacted
> by the install command.

That's exactly the problem. build + install description is too
simplistic for complex builds: you often need to know install options
at build time. You need to know some build options when building
configuration files, you need to pass configuration options to other
subsequent steps, etc...

>
> This is similar to getting the command, (instanciate it + finalize it
> if it doesn't exists yet)
> and return a finalized option.

This does not solve the issue IMHO. Since we both seem to like
thinking about use-cases, consider this use-case: you have a python
package with a complex extension built with make (say you have a
build_make command which calls a makefile). How do you do it ? How to
communicate path informations, compiler options between make and
distutils ? How to handle relinking (changing rpath at install time) ?

>>
>> I will try to document how scons does it. I think the basic idea could be
>> reused in distutils.
>
> But, you didn't answer: if we add the ability to define a different
> compiler for each Extension,
> will it solve your use case ?

I did not answer because my answer will take time to accurately
summarize tools problems in build tools. We have discussed quite a bit
about those issues in scons as well and I want to be sure that my
answer takes this into account as well.

>
> If you are willing to spend some time in that, I am the guy who can
> commit your patches in Python.

I will try to prepare a couple of patches against the hg repo this WE,

David