RE: Dynamic target: for the sake of clarity

[Zachary Deretsky]

For my own sake as well I would like to understand
how cons computes dependencies and what is the difference between
Gary's and Steven's approaches.

I am working on the Conscript for the crowning project of the build tree, 
the one which builds the product executable.

I'll break my original step 1 into 2 finer steps, A and B.

A. Take [qw(input1.txt input2.txt)] and generate a list
of python files @python_files and/or a text file with this
list, python_files.txt. Some of these python files are repository
files and some are being built and installed into the $EXPORT
tree by the parallel Conscripts.

B. Take the result of A., @python_files or python_files.txt
and generate a parallel list @c_files and/or text file, c_files.txt.
In Gary's approach make c_files.txt a target of a Command.

C. Take the list from B., append one more c source file, main.c
and call the Program method to obtain result.exe

Now, result.exe should be rebuilt in case input1.txt or input2.txt
or main.c change and in the case the list @python_files changes or 
any of the file members of that list change.

How does each method ensure that this happens?

In Steven's approach will the perl code (combining A. and B.)
be executed on every cons invocation? Will the MD5 checksums
kept for the @c_files?

Sould I add something like
Depends $CONS 'result.exe', @python_files;

or, since @python_files is not static

Depends $CONS 'result.exe', python_files.txt;
$CONS->QuickScan(\&cons::my_txt_Scan, "python_files.txt", $PYTHON_PATH);

?

Thanks, Zach.

> -----Original Message-----
> From: address@hidden [mailto:address@hidden
> Behalf Of Steven Knight
> Sent: Wednesday, November 15, 2000 3:13 PM
> To: Gary Oberbrunner
> Cc: Zachary Deretsky; address@hidden
> Subject: Re: Dynamic target
> 
> 
> >   ZD> 1. The first step takes 2 input text files and generates a set
> >   ZD> of .c files.  These files will all get the same prefix, but
> >   ZD> other than that I do not know the names of these files or the
> >   ZD> size of the set in advance.
> > 
> >   ZD> 2. The second step compiles and links these files into an
> >   ZD> executable.
> > 
> > Hi, Zach.  This is exactly what we do here.  My solution is as
> > follows:
> > 
> > 1. You need my AfterBuild patch, which allows you to execute code
> >    after a specified target is built.
> > 
> > 2. In your first step, also generate a list of the .c files into a
> >    text file.  Mention that file as one of the targets of 
> your step 1
> >    command.
> > 
> > 3. Write an AfterBuild action (in my AfterBuild patch) for the above
> >    text file, which should just add each filename seen into 
> the link.
> >    (You may need to futz with this; I build a DLL, and cons 
> knows how
> >    to do that in sections; Command and Program don't.)
> > 
> > 4. Use your regular Command/Program target to define the main
> >    executable.
> 
> If the input text files are source files (i.e., aren't generated by
> an action), then you could do this more simply by executing step 1 in
> straight perl, either coded directly or by calling a utility to do it,
> like so:
> 
>       @c_files = `generate_list input1.txt input2.txt`;
>       Program $env 'output.exe', @c_files;
> 
> If the input text files are generated by other Cons actions, then you
> need something like Gary's AfterBuild patch.
> 
>       --SK
> 
> 
> _______________________________________________
> address@hidden
> http://mail.gnu.org/mailman/listinfo/cons-discuss
> Cons URL: http://www.dsmit.com/cons/
>