Re: 2 pure and one bastard models

[Steven Knight]

On Fri, 1 Dec 2000, Zachary Deretsky wrote:
> The two pure models are: Conscript-based model and directory-based model.
> 
> Conscript-based "Conscript-uptodate" model allows developers aggregate
> targets into one developer-defined target.
> 
> Directory-based model defines extra targets based on the directory
> structure and does not afford the aforementioned freedom.
> 
> The model, which I described in my previous posting is the bastard
> between these two: it associated Conscript files with directories.
> Call it "Directory/Conscript" model.
> 
> >     A/Conscript:
> >             Program $env 'foo', 'foo.c';
> >             Install $env '/usr/bin', 'foo';
> >
> >If I say:
> >
> >     % cons A
> >
> >I think it should only build 'A/foo'.  It should not install it in
> >/usr/bin just because the Install happens to be defined there.
> 
> Both the "Conscript-uptodate" model and "Directory/Conscript" model
> would do what cons does today by executing: cons A/Conscript.

Zachary, I think this shows that you misunderstand something about how
Cons already works.  How Cons builds command-line targets *already*
works the way I described.  "cons A" does not read up only A/Conscript
and then "execute" all its directives.  Every time you run it, Cons reads
up the Construct file and *all* Conscript files (specified via Build)
in the entire tree.  Consequently, in the above example, "cons A" does
not install /usr/bin/foo.

If you specify targets on the command line, Cons only builds those
targets and their dependencies.  There is already code in Cons to
interpret directories on the command line and expand them to mean "all
targets within this directory."  The change I'm suggesting would be to
make this logic not special to command-line arguments, but to put it
into the internal node structure so you could use directories anywhere
in a Conscript file, not just on the command line.

Cons does not "execute" Conscript files in the way that Make "executes"
Makefiles.  This is why I made the point about Conscript files simply
being dependency configuration files, independent of the targets you
want built or not.  I realize that you're thinking of the analogy of

        (cd subsystem; make install)

to install just one subsystem's products into /usr/bin, etc.  But this
works for Make because every recursive Make invocation recomputes its
own global dependency information.  Cons computes one set of global
dependencies and then builds targets based on that information.  In other
words, the two have very different dependency and execution models.
I'm in favor of features that add more flexibility and make things
easier for people making the transition from Make to Cons, but not if
they require breaking the existing Cons model.

> >Even though it's different than your understanding as described above,
> >can you see anything that a directory-as-target model like this wouldn't
> >allow you to do?
> 
> The main difficulty in having EXPORT directories as targets is that it
> does not allow enough freedom: all or nothing.

...so how about if we resurrect *another* idea that's been kicked around
on the mailing list in the past:  Alias targets.  The idea would be
to put back a little bit of the usefulness of Make's "special" targets
by providing a way to expand an alias into multiple targets:

        Alias 'install', qw(/usr/bin/my_prog1 /usr/bin/my_prog2);

It should be easy to see how you could use this to subdivide a build.

> Directory-based model brings new convenience and is, apparently,
> easier to implement because the structures for directories are already
> there.
> I don't see, however, how it could be used to Install whatever is relevant
> to particular Conscript into the export tree.
> 
> "Conscript-uptodate" model allows developers to aggregate targets according
> to their human whims independent of the directory tree. I wonder how
> hard would it be to implement it? We could generate files corresponding
> to each Conscript either in its source/build directory or in the
> Construct or export area. The favor that cons would provide is to
> compute all the targets of every Conscript instead of deevloper
> listing them manually plus create the dummy file.

It's less a question of how easy it would be to implement one or the
other than that one conforms to and extends Cons' dependency model,
while the other changes some existing Cons semantics about targets.

> >This brings up a subtle but very important point:  in the general case,
> >it doesn't matter where the Conscript files live.
> 
> I do want to have the ability to make it matter (not where the file lives,
> but which targets it contains).

What you suggest doesn't just change which targets the Conscript file
contains.  More importantly, it changes the semantics of when those
targets get built.  You'd like any target, anywhere to be built/installed
because you "executed" its Conscript file.  I can't see making this large
a change to Cons' dependency.  It wouldn't be Cons anymore, it would be
Make with Cons-like configuration files.

>                                 In many cases cons cannot construct the
> necessary dependency tree by itself, Depends and QuickScan are available
> to developers to aid cons in constructing dependency tree before work
> begins. So, calling Depends on "Conscript-uptodate" target is another
> way to relate developer exterior knowledge to cons.
> 
> What do you think?

I agree that you're raising a lot of good points about additional
flexibility that Cons needs to accomodate large-scale projects, and you
deserve a lot of credit for that.  I really don't think that making the
Conscript files themselves part of the build-target mechanism is the
way to go about this, though.

But I'm confident that if we keep at this, we can come up with the right
set of mechanisms to add that flexibility you (and others) need without
changing parts of Cons that people have come to rely on.

Thanks for all of the thoughtful commentary.

        --SK