On Fri, Nov 13, 2009 at 11:26:23AM +0100, Tarek Ziadé wrote:
On Fri, Nov 13, 2009 at 6:22 AM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Tarek Ziadé wrote:
A deprecation warning would be added in install, if it finds a local option, rather than a global. Meaning both would work in 2.7/3.2.
If changing the command line in incompatible ways is acceptable, what do you think of scrapping the commands (at the UI level only) altogether ? This would be more consistent and easier to deal for the user, and easier to implement as well:
python setup.py configure --option1 --option2=value2 .... python setup.py build python setup.py install
We could then make this work:
python setup.py install (would run both build and configure implicitly). Making all finalized options available at the build stage would then be easier.
Is that scraping, or just preparing finalized options using "configure" ? Meaning other command would just have to get them when they run, if present ?
How would that work ? configure would create a file ?
That would be the obvious solution. Both autoconf and CPAN do this by my understanding so it's a pretty logical thing to do.
It seems that you are pushing all the work in the "configure" option, wich is fine to me, but it also looks like you can already achieve this with the existing system, by changing the subcommands that are in the install command and their order. That is:
install configure build all the install_*
But if we want to see this working with "build" alone, configure has to be a subcommand of build:
install build configure all the install_*
Would it not be harder to add new command (or "build tasks") that require information from the configure step in you structure it like this? Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org