RE: [scons-devel] LinkedModule and files from subordinate SConscripts

[Steven Knight]

[cons-discuss subscribers:  I cc'ed this in-progress thread from the
scons-devel mailing list due to discussion of Cons' LinkedModule method.
Apologies for the off-topic SCons discussion at the end.  --SK]

On Fri, 20 Jul 2001, Charles Crain wrote:
> Cool.  Yeah, it has always been mysterious to me why LinkedModule is not in
> the Cons docs, but IS in the FAQ and clearly does work (I use it in several
> of my projects).  I ought to find out if it has been intentionally
> deprecated, and if so, why.

No, it hasn't been deprecated; it was oversight.  There was a lot
of stuff that got thrown into Cons and not documented in its first
couple of years.  I tried to clean that up and supply a lot of missing
documentation, but LinkedModule plain and simple got by me (probably
because I don't use it).

>                              I *have* found at least one interesting bug
> with respect to LinkedModule in the latest Cons release...as I described,
> you can actually have several LinkedModule commands that specify the same
> file as a target, and that will cause all of them to "stack" their output
> objects on to that file.  Problem is, Cons has some safety code to make sure
> you aren't trying to build the same file from two different places with
> different construction environments.  LinkedModule *should* be a special
> case here, since it is the only command that can build a "piece" of a file
> (by stacking objects on top of it) rather than the whole thing, but it
> isn't.  So, all objects that go into a LinkedModule in Cons must have the
> same construction environment, which limits your flexibility.
>
> I am not mentioning the above by way of saying we should have the same
> limitation in SCons, but the presence of such an obvious bug worries me that
> LinkedModule may have been abandoned/deprecated for other reasons.  In fact,
> when I posted the bug on the cons mailing list, I was completely ignored.

Sorry about the silence.  For my part, I didn't really understand the
issue(s) with LinkedModule until your email exchange here.

This bug crept in mainly due to lack of a Cons test case for
LinkedModule, which is another side effect of its lack of documentation.
Most of the test cases got created as need came up, and there hadn't
been need previously.  I agree that LinkedModule should be fixed, and
documented.

> The problem with LinkedModule is that the semantics are so weird compared to
> any other construction command.  Since the file is built in pieces by
> potentially several LinkedModule commands, you have to make sure they all
> get executed to build the file.  And, it pretty much makes no sense (or at
> least is very dangerous) to specify a LinkedModule output file as
> "precious," so we would probably want to disallow that.  Basically, it
> involves some interesting special case code.  And we have to ask ourselves,
> how do we extend the building mechanism to allow user-created builders to
> have these special semantics if they so desire.

In Cons, this should be pretty easy to do by writing a
build::command::linkedmodule::find() method that relaxes
the same-environment restriction, instead of inheriting
build::command::find().

We'll need similar functionality for people writing SCons builders.
How about a set of keyword arguments that will then generate the right
builder logic automatically, something like:

        LinkedModule = Builder(find = multiple_builds, action = "...")

This would instruct the Builder method to construct the LinkedModule
object in such a way as to allow multiple "builds" of the same target
file using that builder.  In essence, there will be a canned set of
find(), compatible(), etc. methods that provide different functionality
and get mixed-and-matched in response to the keyword arguments.  This
will need a lot of good documentation.

If there's no canned method, you can roll your own by supplying a code
object.

No, this isn't in the ScCons design draft, I'm making it up as I go
along.  Comforting, isn't it?

> NOW, as far as returning cool stuff from the SConscript method...this is an
> open issue.  Since it is something neither dealt with in the SCons proposal
> or in our de-facto prototype, Perl-Cons, I am tempted to punt on it until a
> later release, since issues like "what do we return?" or "what are some
> typical use cases for using return values from an SConscript?" have to be
> discussed, and I think we might get a better idea what the requirements of
> such a feature are after we've released something.

This sounds very prudent.  It's a cool idea to keep in the back pocket,
though, until we're smarter about what we want it to do.

        --SK