Re: Some questions for Cons

[Gary Oberbrunner]

I thought this might be a good time to send out a quick overview of how 
we use cons here.  If others are setting up cons from scratch, this is a 
model that's proved out pretty well here -- it's based of course on a 
lot of ideas from this mailing list.  Comments are welcome of course! 
Unfortunately I can't really send out working code; it's far too long 
and anyway it's pretty specialized.  But the general method is OK I think.

In addition to the usual Construct at top level and Conscripts sprinkled 
about, we have two additional files at top level: Cons-defs.pl and 
ConsSubs.pm.

ConsSubs.pm contains all the useful methods like syntactic sugar for all 
our weird source generators, OS determination, finding local paths to 
things we need, special ways of building things, etc.  We 'use' this 
into Construct and all the Conscripts.

Cons-defs.pl is 'require'd into Construct, but not the Conscripts.  It's 
responsible for setting up the default environment, accounting for all 
the variations of OS, compiler, product, debug/final, etc.  It basically 
 goes from the cmd line args and default settings into a hash of config 
information; then from that config it creates the environment in a hash 
(%env), and only at the very end does it define the default environment 
from that hash using cons->new(%env).  This way we can add and subtract 
things at will.  (You can't modify a cons environment once it's created.)

The command-line parsing also happens at two levels: high-level args 
like -final set up things for a "standard" final build, but there are 
also low-level args to turn on/off optimization, stripping, doc 
generation, etc., so you can say -final -nostrip to get a final-type 
build with symbols.  These args fill in a %cfg hash which has all the 
info we'll use to set up the environment.

Here's the overall flow:

 - get all cmd line args into a big %cfg hash (we use GetOpt::Long)
   but don't do anything with them yet.
 - parse certain initial args like verbose and conscript_debug.

 - go through the high-level args, setting values in %cfg.
 - go through low-level args, overriding %cfg values.
 - use %cfg to set %env hash.  This takes a few phases:
   - start with standard cons (or Cons::Plus) env, flatten into a hash.
   - override with standard stuff, like CFLAGS, CPPCOM, DEFINES, etc.

  - depending on which version of our product is being built,

     modify a bunch of stuff according to %cfg.
   - depending on which OS we're building on, modify paths, flags, etc.

In our world, this setting %env from %cfg is over 400 lines.  Things get 
complex.

Then pretty much everything you could need is in that default 
environment, so not much except that needs to be EXPORT/IMPORTed.  This 
way our Construct and Conscripts stay very clean.  No method 
definitions, just very straightforward applications of the environment.

Perhaps this seems like overkill, it's certainly more involved than what 
you see in the simple cons docs.  It certainly would be too much for a 
small project, but but we find it gives the flexibility we need while 
making it pretty clear where each part is defined and where to go to 
change something if something's not working.

I hope this is useful to people!

-- Gary Oberbrunner