cons-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Modularizing cons (was: patch for static linking)


From: Steven Knight
Subject: Re: Modularizing cons (was: patch for static linking)
Date: Fri, 31 Aug 2001 13:42:56 -0500 (CDT)

>  > > 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.

Why does adding the above logic bother you, when the logic for
interpreting %LIBS and %LIBPATH and %PREFLIB and %SUFLIB are all "in
there," too?  It seems to me that all of these are simply different ways
of interpreting construction variables to control a link operation in
more and more sophisticated ways.

>  > Yet another argument for modularizing cons.
>
> I agree SO MUCH!

Amen to that.

>                   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.

So where does the line get drawn?  If both someone else's linker command
use similar static/dynamic flags to mine, why should my builder have to
duplicate that logic, but not the %LIBPATH logic?  Or does each builder
always roll its own from scratch?

> 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.

I like the init_env() piece.  Right now, with all of the construction
variables just thrown into the ruleset, there's too much undocumented
magic about which methods use which variables.  Something like this
would make it easier to keep the logic in one place.

> 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.

Agreed, with one exception: scanning for includes doesn't belong with
the build tool, it belongs in a separate scanner object that's tied to
the type of file being scanned.  All C files use the same #include logic
and should use the same scanner object to find those, regardless of the
compiler use to turn it into a .o/.obj/whatever.

> 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.

This is a good idea, too; it would be easier if we were a little more
"purely" Object Oriented in how Cons uses Perl.

> 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.

The other piece that's nonobvious (to me, at least) is how to split this
up into Perl modules so you can "include" the canned builders/scanners
that you want, and not have to worry about the others.

>  > 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!

Amen again.  What we're starting to talk about is a pretty significant
redesign, so here's the big open question:  Does all of this need to
maintain backwards compatibility with the current Cons, or are people
open to a *complete* rework for a hypothetical Cons 3.0, and losing
backwards compatibility?

        --SK




reply via email to

[Prev in Thread] Current Thread [Next in Thread]