RE: Cons not working as advertized and other remarks

[Charles Crain]

<snip>
die 'somethin' unless $OS = $ARG{OS} ;
</snip>

The example above assumes that you supply "OS=foo" on the command line when
you run Cons, such as:
cons OS=windows .

I use this approach in several of my Conscripts, with great success.

<snip>
The example with OS=peach or banana is a good example for how to get
arguments (when it works :-) but that is not what I call a variant build;
it's the same build in another directory. the two last paragraphs of that
section point  towards two examples of variant builds but there are no
examples. I know how difficult it is to document ones program for beginners
and I am quite happy that there IS a documentation. but please thinnk about
new comers.

Another point: One has to gess how variant builds work. my guess is a
somehow magical assignement to the special variable $EXPORT (no you don't
mession anything about it) added with some Install commands. Is that the
right guess ?
</snip>

The idea is usually that you have a hierarchy of Conscripts that invoke each
other with the Build command.  In my projects, I often have a top level
Conscript that sets up any variables for the build based on command line
arguments (specifying target platform, release vs. debug build, etc.), and
then builds all the variant-independent stuff.  I then call other
Conscript(s) that are specific to the particular build.

<snip>
A last word about Scons. (please let's keep the perl-python dumb war out of
this list) What's the use to rewrite a properly working program to python?
Is it to be happy with it or did you add any functionalities? wouldn't it
have better to add functionality to cons instead?
</snip>

I'm part of the SCons project.  The idea I get from Steve Knight is that
Cons has always been a prototype.  Looking at the Perl code, it's all in one
big file, all mushed together, lots of hacks, difficult to maintain or
enhance significantly.  All stuff you'd expect from a prototype.

Python as a language is better suited to larger-scale, ongoing projects, as
we want SCons to be.  There are other reasons for the choice of Python over
Perl...I don't want to risk sparking a holy war by enumerating all of them.
Suffice it to say that one of our main objectives was to make SCons
accessible to people who are not Python experts.  As a non-Perl-expert, I
feel significantly hampered when using Cons due to Perl's, shall we say,
creative syntax rules.  Python's syntax (at least at the most basic level)
is more intuitive, and I believe it meets our goal of accessibility to
Python newbies well.

Finally, the SCons proposal is what won the Software Carpentry contest after
all!  You'd have to ask Steve for his reasons for proposing the project in
Python rather than Perl, but I for one am glad he did.  Mainly because I
would not have been able to contribute nearly as much!

-Charles