Directory targets: specifics

[Zachary Deretsky]

> > I like it.  It's not exactly the same as Zachary's model,
> because you
> > can have more than one Conscript per directory or more than one
> > directory per Conscript.  But it seems like a good compromise to me.
> > Could this be extended to do something at the very end, when all
> > targets are built?  Zachary's model can, by something like
> > Construct-up-to-date (instead of Conscript).  Maybe there could be a
> > special dir target of "/" or something?  Then we wouldn't need
> > AfterBuildAll.
>
> Exactly.  If all your targets are under the top-level directory, you
> could AfterBuild '.' to have an end-of-build action.  If you install
> things outside the top-level directory, AfterBuild of the installation
> director{y,ies} or AfterBuild '/' would accomplish the same thing.
>
>       --SK

Gentlemen,

I am very impressed by the cooperative spirit of our discussion.

Directory targets are very appealing and would provide me all the
convenience and flexibility which I need.

I would like to bounce around specifics:

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.

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

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

5. This model (agregating Conscripts per directory) is cumbersome
in the situation when 2 Conscripts call different Conscripts in one
directory:

A/Conscript
        Build("C/Conscript1");

B/Conscript
        Build("C/Conscript2");

Under this model A will depend on all the targets of C (Conscript1 and
Conscript2)
and the same is true for B.

Although there are unnecessary dependencies, this does not create new
cycles,
so it is tolerable.

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

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.

Thanks, Zach.