[Distutils] RE: autoconf in distutils

gward@cnri.reston.va.us gward@cnri.reston.va.us
Tue, 20 Jul 1999 10:49:32 -0400


On 20 July 1999, Anthony Pfrunder said:
> I've been following distutils with interest and would like to share a few
> thoughts:
> 	* Some people may wish to compile blind or get feedback as it goes
> 	  ie a known working product ppl probably just want to know when
> 	  the build is finished.  For an in-development one they may want
>  	  compile time feedback
> 
> 	* During install stage, people may want feedback or a "quiet"
> 	  install.

Currently handled by the '-v/--verbose' flag, which affects any
Distutils command class that plays by "the rules".  See
distutils/command/{build,install}_py.py for examples, or download the
Distutils and run

   python setup.py build

versus

   python setup.py -v build

to see the difference.

In summary, -v is quite verbose: every individual filesystem-affecting
operation (copy a file, compile a file, etc.) prints a line of text.
Quiet mode is the default, and is very quiet; only error messages are
printed.  (Or at least that's the idea: if you see different behaviour,
that's a bug so let me know.  Or it might be an inadvertent feature, in
which case I'll have to change the definition of "verbose".  ;-)

A middle ground would be nice, eg. just print "copying Python source",
"compiling extensions", "installing", etc. but don't show the gory
details.  This would be a sensible default.

Anyone have a nice way to implement multi-level verbosity this without
making -v take a cryptic numeric "verbosity level"?  (Actually, the code
has support for verbosity levels, but I'm not sure how best to expose
this to the user on the command line.)  I've never been a big fan of
either "--verbose=37" or "-vvvvv".

> 	* People may wish to import makefiles and output them in a
> 	  platform specific format (ie Visual C for debugging).  This
> 	  could be done by merging David Aschers compy program into
> 	  distutil.  Distutil could have a load and save option to perform
> 	  this

Exporting makefiles is an option which I planned initially.  Since I've
gone and implemented the easy part of make's functionality in Python
(ie. compare datestamps and run commands to generate out-of-date files
-- no makefile parsing, no DAG building, and no topographic sorting),
this may not as necessary/useful as I initially thought.  But it could
always be revived.

By importing, I certainly hope you don't propose writing a complete
makefile parser!  Were you thinking of parsing the particular flavour of
Makefile generated from Makefile.pre.in?  I'm not sure I see the utility 
in that... please explain!

        Greg
-- 
Greg Ward - software developer                    gward@cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913