2 pure and one bastard models

[Zachary Deretsky]

Gary:
> If I misinterpreted you and you just mean that the A directory target
> isn't considered up-to-date until B is also up-to-date, then I'm fine

I mean exactly that: directory A target isn't concidered uptodate until
all of its targets are built.

Steven:
>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?

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

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

Here is what happens with my individual projects:

some of them deal with python files which originate in 3 ways:

a) are taken from a repository
b) live in the source directory
c) are generated by Commands in the build directory

All of these get installed into the PYTHON directory (parallel to the export
bin, lib, include).

So, if an app project depends on this utility project, then it needs only
its
python files installed, not all of the PYTHON export directory. Moreover,
using the export directories as dependencies will, probaly, often create
circular
dependencies.

In conclusion:

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.

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


Zach.