Modularizing cons (was: patch for static linking)

[Gary Oberbrunner]

 > > Aha.  Okay, then I'll suggest that, rather than making it
tool-specific,
 > > we add some construction variables to make the options settable:
 > >
 > >    new cons(DYNAMIC_ONLY_LIB_FLAGS => ['-Wl,-Bdynamic',
 > >                                    '-Wl,-dy',
 > >                                    '-Wl,-call_shared'],
 > >             STATIC_ONLY_LIB_FLAGS => ['-Wl,-Bstatic',
 > >                                    '-WL,-static',
 > >                                    '-Wl,-dn',
 > >                                    '-Wl,-non_shared']);
 > > I'm just really leery about tool-specific stuff in the guts of Cons.
 > > As much as possible, I think we should do stuff through setting (and
 > > therefore creating) appropriate construction variables...

Doing it this way gets the specific strings out of cons's guts, yes, but the
*logic* is still in there, and it disturbs me that it has to be like that
(unlike make, which can be so much more tool-agnostic -- admittedly because
it does so much less for you).  What happens when someone invents a linker
flag that makes it ONLY link with dynamic libs?  Then cons has to be patched
again.  Or a pseudo-linker that uses a different path search method.  Or
Irix, which uses LD_LIBRARY_PATH(*), or whatever.

 > Yet another argument for modularizing cons.

I agree SO MUCH!  I just hate to see cons's build::command::link getting
lots of these warts on it to support all possible variants of
compiler/linker etc.  There's got to be a more modular way to extract all of
this tool-specific knowledge so it can all live in one place.  I'm not sure
how to go about it cleanly though.  A certain amount of the core command
logic should stay in cons to make tool ports easier, but at some point cons
is going to have to call out to code refs defined by each tool to do the
real work.

Here's a really simple straw-man.  Sorry I don't have more time right now,
but see what you think, or feel free to propose alternatives.

A tool (compiler, linker, source-generator, whatever) is defined by a perl
object class.  That object contains the following public methods:
  register(), which registers the class with cons.
  init_env($env) which adds all the tool's default construction vars to
    a default env.  Cons calls all the init_env methods for all registered
    tools whenever it generates a new env from scratch.

Everything else a tool does is via the construction vars, which in this case
are likely to be code refs as well as strings.  Some of those would be
things to replace the library search method, scan for includes, and so on.
The code-ref var names would all be defined by cons.

For instance if a tool wants to add a way to scan particular C source files,
replacing the usual method, it could override the default c scanner with its
own.  If the name matches a regexp it could do its own thing, and if not
it'd just call the original c scanner, which it would remember maybe by
storing a hash in its private namespace mapping from each env to its private
data or else cons could put the tool object into the env, named so the tool
could find it later.

Of course tools can also add new top-level cons commands in the usual way.
A lot of Windows stuff could be done like this: WindowsResourceFile, and so
on.

Is there any way a tool could globally override a given method, for instance
the Library method (like the cons::switch example in the cons doc)?
Perhaps it's as simple as the tool redefining cons::Library.  Of course this
is not for the faint of heart, and the tool would then be probably too
closely linked to cons's calling conventions and so on, but I think it would
at least allow a tool to wrap the regular method with its own code -- that
would undoubtedly be useful.

I guess the hard part of all of this will be deciding, on a per-method
basis, what is "base cons functionality" and what belongs in a particular
tool and so should be abstracted out, and making sure the infrastructure is
stable enough that the tool ports won't all have to change just because cons
does.  This'll have to evolve over time.

 > So, who's got time to modularize cons?  ;^)

I'm willing to help define it at least, and I'll put in some effort too once
people agree on a way forward.  I think this should be THE top priority for
"real" cons work (as opposed to little bug fixes) -- it'll really open it up
for all kinds of new uses, it'll clean up the guts so it'll be more
comprehensible, and hopefully that will help it attract more users!

-- Gary Oberbrunner