Musings: Conscript-uptodate targets

[Zachary Deretsky]

>
> So I've also been thinking about something like Marcello's
> AfterBuildAll idea, which would add a shell string (or perl code ref,
> excellent suggestion Steven), to a list of things to be done at the
> end.  The list would be run only if the build succeeded and something
> was done.  If I had this, I don't think I'd even need my wrapper shell
> script.
>
> 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.

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.

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.

If I were creating a new sofwtare system with cons myself or in a very small
group of very mature software developers, I would certainly use Steven's
strict model.

Instead I am converting to cons a large system, result of 4 years of work
by many people. Note that many decisions are not mine, and certain things
are easy to alter, while certain things are hard to change.

At the start we decided to subdivide our work into similarly looking
projects. We develop on NT, plus build and sell on Unix. So, we made
a tool which originally generated template nmake files and now
.dsp/ .dsw files for projects. These projects generally create one
shared object and a bunch of executables. All the sources for a
project are kept in one directory. Having these more-or-less
uniform projects makes it easier to train new employees and to switch
between projects. They also helped to tame the Visual Studio into
consistent behavior.

We also bought source code from another company which has similar
stucture with its own idiosycrasies.

Now, some projects are utility projects and some are application
projects which depend on a subtree of utility projects.

The main driver project does not link with application shared
objects, but can register python scenarios and load these
applicatins dynamically and run them within its GUI.

This way we can easily add and remove apps and market different
product configurations.

Our checker scripts require the driver to be built plus whatever
apps the scripts use to be built and installed. They are all
run in one project at the end now, but can be separated into several
Conscripts and depend only on the apps they need.

Current build system can also send email to the owners of failed projects,
so it is good to know when a project is built and when something
within a project fails.

I hope that this gives the gist of why the strict dependency use model
is harder to apply here than "Conscript-uptodate" use model.

I believe, this would be generally the case for converting
large legacy projects to cons.

I rest my case here.

Thanks, Zach.