On Fri, Nov 13, 2009 at 7:12 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
On Thu, Nov 12, 2009 at 12:31 PM, Pauli Virtanen <pav+sp@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