On Sun, Nov 15, 2009 at 3:44 AM, Jeremy Kloth <jeremy.kl...@gmail.com> wrote: [..] >> So did you end up changing the way options are passed to the commands, >> or do you just have a specific "config" command that looks over other >> options passed to the other commands ? > > It is done with the 'config' command having all the options used by the other > commands. The other commands would then look up their options' values from > 'config' (if not supplied on the command-line). If, for example, `--prefix` > was supplied to 'install', the 'install' command would then cause the 'config' > to redo its stored options. > > If at all possible, I would eliminate the redundant options on > build_*/install_* and leave them solely on 'config' as it greatly simplifies > the interaction of the commands.
So, pratically speaking, if: $ python setup.py install is called, the install command will instanciate the configure command, that will return options that were stored in some file, in a previous call ? But, for the option redundancy problem, the simplest way I can see to have the "configure" options in "install", or to let the end user pass them along, would be to make "configure" the base class for all commands that are part of the configure-make-install story, so when they run they can read and write options in the stored file and use if needed the options passed in the command line. Tarek _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig