Re: Desired feature: Conscript-uptodate targets

[Gary Oberbrunner]

>>>>> "ZD" == Zachary Deretsky <address@hidden> writes:

  >> > input*.txt contain a list of directories with Conscripts
  >> > where python files are generated and Installed.
  >> >
  >> > I am generating python_files.txt with the list of those
  >> > files, but these files HAVE to be built and installed BEFORE
  >> > proceeding further.
  >> 
  >> > Maybe, the easiest is to ensure that those sibling Conscripts
  >> > are built before the current one. It is against cons philosopy
  >> > to prescribe the order of builds and installs, but is there a
  >> > trick to do that? Depends on PHONEY targets?
  >> 
  >> What you essentially need is a way to read up a subset of the
  >> Conscript
  >> files, build one or more targets, and then read other Conscript files.
  >> There isn't any way to do this; the right solution to it is
  >> Gary's AfterBuild
  >> 


  ZD> I do not see how AfterBuild can force files from the sibling
  ZD> projects to be built and Installed. Will it do that?

First, don't think about separate Conscripts as "sibling projects."
In cons it's all one project.  Things live in different subdirs, but
they're all part of the same dependency tree (that's the whole point,
really).

Sometimes the easiest thing to do, like with your regression test
example, is to run cons twice: once to build all, then again to run
the tests.  (With different Construct/scripts or different cmd line
args, of course.)

However, all that said, let's see if it can work as you wish.
AfterBuild and AddTarget *can* force new targets to be built and
installed.  Here's one way.  Let's use your regression test example,
and assume each regression test writes out a log file (to use as its
target).

For each regular Program target (or maybe Install target, depending on
where you want to run the tests from), use AfterBuild to AddTarget the
test's log file.  Then either statically (in the Conscript) or
dynamically (in the AfterBuild code) add a RunRegressionTest method
for each test to be run, producing the log file you just AddTarget'ed.

AddTarget'ed targets don't get looked at until all the regular
(statically defined) targets are built, so your regression tests will
all be run after the commands are built.  Of course this is really a
semi-bogus dependency, since you could in theory run regression test 1
as soon as program 1 is built.

  ZD> What is your opinion on the following idea:

  ZD> For every #/foo/bar/Conscript establish internal
  ZD> "Conscript-uptodate" target foo_bar_Conscript.

The problem with this is that things normally get built in whatever
order works, not conscript-by-conscript.  Forcing this could cause
unsolvable dependency conflicts (you say ConscriptA depends on
ConscriptB, but something in ConscriptB depends on something in
ConscriptA, for instance).

-- 
. . . . . . . . . . . . . . . . . . . . . . . . .
Gary Oberbrunner                address@hidden
GenArts, Inc.                   Tel: 617-492-2888
8 Clinton Street                Fax: 617-492-2852
Cambridge, MA 02139 USA         http://web.genarts.com