RE: Modularizing cons

[Gary Oberbrunner]

Nice work so far, Greg!  I took a quick look at it, and it looks like it can
really succeed in getting the tool-specific stuff out of the base cons.  The
tool-mapping approach is DEFINITELY needed!

I'm conflicted between your OOD approach and the simpler string variable
one.  Your OOD approach is essentially building a set of methods to access
some of the command line params of a compiler, while leaving others
(defines, warnings, etc.) out.  What if someone wants to reorder their
command line params, or add some in a place we didn't expect?  They have to
modify Builder::Compiler::VCXX::GetCommand.  That doesn't seem like a good
idea.  I think the string method is going to be simpler.  But on the other
hand your OOD approach doesn't have the gross _IFLAGS hack; it stores them
in a nice internal format and computes them whenever it wants.

Partly it's a question of how much structure cons imposes vs. how simple it
is for the user has to reorganize things.  If someone uses cons with an
embedded-system compiler, how much work does she have to do to get it going?
Seems like fooling with a few construction string vars is going to be
simpler than cutting & pasting from an existing compiler object.

Your "Process" approach lets you create a builder for any {src,target}
extension pair, but I'm not sure it gives enough flexibility.  If I want to
link some of my .objs into exes, but others into a shared lib, I have to
make a separate env to do that if everything goes through Process -- seems
like it's better to have the user specify the destination type explicitly,
like Program and Library (and SharedLibrary) work now -- they can all take
objs.  You could keep the Process model by just having its first arg be the
destination type -- it could be inferred if omitted.  So if I say
Process('.i', @srcs), it'll preprocess them with cpp, if I've set up the
.c->.i and .cxx->.i mappings.  But it might be simpler to encode the desired
target type into the name, I'm not sure.

Does 'Command' still work the same way in your new scheme?  It has no API,
right, just a command line and sources, as usual?

OK, I have to get back to work now, even though this is more fun! :-)

-- Gary Oberbrunner