On Fri, Nov 13, 2009 at 11:26:23AM +0100, Tarek Ziadé wrote: > On Fri, Nov 13, 2009 at 6:22 AM, David Cournapeau > <da...@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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
