Re: Directory targets: specifics

[Steven Knight]

On Fri, 1 Dec 2000, Zachary Deretsky wrote:
> I am very impressed by the cooperative spirit of our discussion.

I agree, Zachary.  The cooperative exchange of ideas on the mailing list
makes working with Cons very enjoyable.

> 1. More than one Conscript per directory looks like rather rare situation,
> there is seldom more than one Makefile per directory, albeit everything
> is possible. If all combined targets of several Conscripts makeup a
> directory target, then things are consistent for this situation.
> 
> 2. More than one directory per Conscript. This Conscript file lives
> in a particular directory. So, everything which is built through
> this Conscript should be attributed to that directory.

Your first two points are correct for the normal case, but let me point
out one example that might strike you as counter-intuitive:

        subdir/Conscript:
                Program '../foo.exe', @sources;

Even though the target is defined in subdir's Conscript file, the target
is not underneath the subdirectory.  Consequently, I think foo.exe should
*not* be built if you said:

        $ cons subdir

This is because my command said, "Build all targets the exist underneath
subdir," NOT, "Build all targets defined in Conscript files underneath
subdir."

> 3. Which brings me to the main issue here: which targets are attributed
> to a directory? I belive, consistent definition is:
> 
> All the targets of all the Conscripts residing in this directory.

This is why I brought up the previous example.  The consistent definition
for Cons' dependency analysis is, "All targets that actually reside in
the directory (recursively including subdirectories)."  This is close
to your definition, but subtly different.

A different example to illustrate.  Given the following

        A/Conscript:
                Program 'foo', qw(foo1.c foo2.c);
                Program '../B/bar', qw(bar1.c bar2.c);

I think that the consistent behavior would be:

        % cons A
        cc -c A/foo1.c -o A/foo1.o
        cc -c A/foo2.c -o A/foo2.o
        cc -o A/foo A/foo1.o A/foo2.o
        % cons B
        cc -c A/bar1.c -o A/bar1.o
        cc -c A/bar2.c -o A/bar2.o
        cc -o B/bar A/bar1.o A/bar2.o
        %

B/bar is the only target underneath B, so in order for B to be
"up-to-date", it must build B/bar, and the dependencies of B/bar, which
just happen to live back in the A subdirectory.

This brings up a subtle but very important point:  in the general case,
it doesn't matter where the Conscript files live.  Conscript files are
merely configuration files that establish dependencies.  Their location in
the directory tree should not affect which targets do or don't get built.

In other words, you should be able to rewrite the previous example
to this:

        Construct:
                Program 'A/foo', qw(A/foo1.c, A/foo2.c);
                Program 'B/bar', qw(A/bar1.c, A/bar2.c);

or this:

        A/Conscript:
                Program 'foo', qw(foo1.c foo2.c);
        B/Conscript:
                Program 'bar', qw(#A/bar1.c #A/bar2.c);

and have each one build the same targets in the same fashion.  They're all
just different Conscript hierarchies for expressing identical dependency
relationships.

> This handles the case, for example, when files are copied from a
> repository to the install area, not touching the directory,
> where the Conscript with this Command resides in any way.

In order to build targets in the installation directory, you'd have
to supply the installation directory name as the target, just as you
would today.  Given:

        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.  I should
have to say either:

        % cons /usr/bin
        % cons /

To have it install the targets underneath those directories.

> 4. The above implies that if Conscript in directory A has
> Build("B/Conscript");
> then directory A target would depend on directory B.

If B is a subdirectory of A, yes, but because it's a subdirectory of A,
not because it's defined in the A/Conscript file.

> 6. Question: in Link "BuildDir" => "SourceDir" situation which directory
> is the target?

The BuildDir.  You're essentially saying, "Build every target under
diretory X," and the targets exist under the build directory.

> 7. In conclusion, if this is acceptable, then in one-to-one Conscript per
> directory situation it is exactly like my "Conscript-uptodate"
> targets. In the one/many <=> one/many situation I hope we
> have a consitent model, please punch holes in it.

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