[Distutils] working on a build system

[Greg Ward]

Quoth Andrew Dalke, on 06 March 1999:
> My current task here at Bioreason is to set up a build/distrib
> system for our projects.  We're developing pure Python modules,
> Python extensions in C/C++, and stand-alone C++ executables.
> I'm trying to get a basic system that lets use work with these
> in a standard framework and supports automatic regression tests
> with the results emailed or sent to a status web page.

Hmmm, from the first paragraph, it sounds like there's the potential for 
a lot of overlap with Distutils -- or, to look at it more positively, a
lot of potential for you to use Distutils!

The rest of your post diverges a bit from this; certainly, stock,
out-of-the-box Distutils won't be able to handle all the neat stuff you
want to do.  However, the architecture is quite flexible: module
developers will easily be able to add new commands to the system just by 
defining a "command class" that follows a few easy rules.

I posted a design proposal to this list back in January; you might want
to give that a look.  I finally got around to HTMLizing it and putting
it on the Distutils web page a week or so ago, but hadn't announced it
yet because I wanted to tweak it a bit more.  So much for that --
consider this the announcement.  You'll find the design proposal at

    http://www.python.org/sigs/distutils-sig/design.html

By no means is it a comprehensive design; since I've finally started
implementing the Distutils (shh! it's still a secret!), I've found all
sorts of holes.  However, it gives a good idea of the level of
flexibility I'm aiming for.

Note that one big difference between your idea and Distutils is that
we're avoiding dependence on Makefiles: for the most part, they're not
needed, and they're unportable as hell (as you're finding out).  Make
should be used to carry out timestamp-based file dependency analysis,
which means it's just great for building C programs.  When you use it
mainly to bundle up little sequences of shell commands, you're misusing
it.  (For the ultimate example of Makefile abuse, see any Makefile
created by Perl's MakeMaker module.  The most astonishing thing is that
it all *works*...)

> Let me explain that last one some more.  It seems that Perl's "pod"
> format is the easiest to learn and use.

Yes.  XML is waaay cool, but pulls in a hell of a lot of baggage.  Until
that baggage is standard everywhere (hello, Python 1.6 and Perl 5.006!
;-), low-overhead light-weight solutions like pod are probably
preferable.  Heck, even when all the world is Unicode and XML for
everything, low-overhead and light-weight will still be nice (if only to
remember how things were, back in the good ol' days).

> Is there a Python way to read/parse pod files?  If not, using perl for 
> this is fine with us.

As Fred said, it *should* be trivial.  It's a bit trickier if you want a
really flexible framework for processing pod; see Brad Appleton's
Pod::Parser module (available on CPAN) for that.  The current generation
of pod tools that ship with Perl are getting a bit long-in-the-tooth;
they all have their own parsers, and unsurprisingly have diverged
somewhat over the years.  Hopefully Pod::Parser will start to fix this.
My recommendation: spend a few hours learning to use Pod::Parser, and
then write your own custom pod tools (yes, in Perl ;-).  Slightly less
trivial than writing your own custom, limited parser (in either
language), or using pod2text, but should be more robust and scalable.

Anyways, with any luck the Distutils CVS archive will be a lot busier
within a week or so -- so there might actually be something that you
(and everyone else on this SIG!) can muck around with.

Keeping my fingers crossed (except while writing code) --

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