On Fri, Nov 13, 2009 at 7:12 AM, Tarek Ziadé <ziade.ta...@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 12:31 PM, Pauli Virtanen <pav...@iki.fi> wrote:
>> Thu, 12 Nov 2009 10:54:41 +0100, Tarek Ziadé wrote:
>> [clip]
>>>>>>>> get_install_paths('FOO')
>>>>>
>>>>> And that's the API we want to add in sysconfig, roughly.
>>>>
>>>> That does not solve the problem about getting FOO in the first place
>>>> when calling get_install_path.
>>>
>>> Why that ? where "FOO" comes from ? if it's an option you provide at
>>> build time like you said, earlier, you just pass it to the API to get
>>> the paths.
>>>
>>> FOO is not coming from nowhere...
>>
>> If this is not painfully clear already, the user passes FOO to the command
>>
>> python setup.py install --prefix=FOO
>>
>> Now, clearly the distutils install subcommand knows what FOO is.
>> But does build_ext? Does sysconfig?
>
> The install command takes FOO, and build several paths with it:
>
> /FOO/lib/site-package/
> /FOO/xxx
>
> The other commands that needs to get the same path can rebuild it using an
> API,
> that does:
>
> get_paths(scheme, vars={'prefix': 'FOO')
>
> Instead of doing what David did:
>
> $ python setup.py build_ext install --prefix=FOO
>
> They can do:
>
> $ python setup.py build_ext --prefix=FOO
>
> and don't require to use the install command anymore to get these paths
> cooked.
I think I was confusing with my rpath example, which may be the source
of our misunderstanding. I don't want to add a --prefix option to
build_ext. I want to support the following user cases:
python setup.py build # here, prefix would be whatever default, as
available from sysconfig
python setup.py install --prefix=foo # here, prefix would be the one
as computer by install command
python setup.py build_ext -i # here prefix is the current directory
Requiring users to handle new options of commands is impractical IMHO,
and a prefix option to build has a strange feeling to it.
> Remember that the build step has nothing to do with the install step
Ideally, what we want here is like autoconf does it. You have a
configure step, and then at build/install stages, you have access to
*all* options. Those options can be customized at build through usual
make mechanism, but this is taken into account as well without the
makefile writer having to care.
IOW, we need to know *all* the finalized options *before* the first
build command is even run.
David
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
