Re: Musings: Conscript-uptodate targets

[Steven Knight]

On Thu, 30 Nov 2000, Zachary Deretsky wrote:
> > But perhaps, as Steven says, I only think I need this because I'm
> > lazy: if I'd integrate all of what I consider "post-build" stuff into
> > cons with proper targets and dependencies, I probably wouldn't need
> > any of this.  Except... email-sending is one of those things that you
> > really shouldn't have to add a dependency on every final target for.
> > And determining the dependencies for building the setup program can be
> > a real nightmare.  If you miss one, your setup program could be built
> > before the last target! So those two seem to be a good case for
> > AfterBuildAll.  Maybe once I dig myself out from under my current
> > pile, I'll take a look at it.
> 
> Firstly, I agree with everything that Steven wrote and I find his small
> examples very useful because they demonstrate a certain use model.
> 
> Secondly, I would like to point out that I can achieve everything I need
> with the existing cons, by hook or crook, I just suggested a convenience
> feature, which does NOT maim any existing use models, but adds ease for
> another use model.

Good point, features for convenience are worth considering.  But it's
also worth trying to figure out if, rather than adding a completely
new feature, an existing mechanism can be adapted in some way, to avoid
feature creep.  Which brings me to...

> Thirdly, I think, that "Conscript-uptodate" targets allow to do everything
> AfterBuildAll would allow, but are more flexible because they allow
> to perfom actions based on any subset of uptodate sub-projects.

...what if this were accomplished, not by a separate Conscript target,
but by a dependency on the *directory* in which the Conscript file lives?

Right now, Cons' internal file nodes and directory nodes are *nearly*
internally equivalent for a number of key properties, but not for
dependency analysis.  Expansion of command-line targets happens in a
top-level loop, outside normal dependency analysis.

I've thought for a while that directories could be handled like any
other target, and that the dependencies of a directory would be all of
the targets within that directory.  The practical upshot is that I want
to be able to do something like the following to be able to tar up a
subdirectory's derived files:

        Command $env 'sub-dir.tar.gz', 'sub/dir', qq(
                tar zcf %> %<
        );

But you can't do this in Cons right now, because you can't specify a
directory as a dependency.

Note that if you could "build" a directory in this way, then using Gary's
patch, you could also specify an AfterBuild action for the target.

If Cons had this capability, would that solve the things you're looking
for with a special "Conscript-uptodate" target?

> And, forthly, I would like to tell about our software environment here,
> so that I am understood more fully (isn't that everybody's goal?).
> And I will not try to prove that I definitely need this or that, I
> just want to relate the issues that I face.

Many thanks for all of the detail about your build situation.  It's always
good to have complex, real-world examples in mind to make sure that
things don't get implemented too narrowly.

        --SK