Re: Could you share and shed some wisdom?

[Steven Knight]

[I added cons-discuss to the CC: on this so everyone could see Gary's
reply to Zachary, as well as my added comment about code refs.  --SK]

On Wed, 29 Nov 2000, Gary Oberbrunner wrote:
> >>>>> "ZD" == Zachary Deretsky <address@hidden> writes:
>   ZD> My first Command creates a set <C_FILES> of new .c files.
>   ZD> The files do not exist and the the set is not known in advance
>   ZD> before Command is run.
> 
>   ZD> Next a Program method should use <C_FILES> as <source or object files>.
> 
>   ZD> Is this doable at all or did I stumble upon a major problem?
>   ZD> Should I call Program from AfterBuild, and if yes, then how do I pass
>   ZD> <C_FILES>?
> 
> In the first Command, also generate a list file, c-files.list, of all
> the new .c files.  Make sure c-files.list is listed as a target of
> that first Command.  Then use AfterBuild on it, something like this:
> 
>  my $cl = FilePath($clistfile);
>  AfterBuild $doc_env ($clistfile,
>                     qq(scan_clist('$cl');));
> 
> Yes, the quoting is hard to get right in the AfterBuild action.  If
> anyone knows how to simplify it, let me know.

I've been integrating AfterBuild, and plan to extend your patch
to take either a string or a code reference.  This should simplify
the quoting by allowing you to use anonymous subroutines:

        my $cl = FilePath($clistfile);
        AfterBuild $doc_env $clistfile, sub { scan_clist($cl) };

I'm going to extend Command in the same way.  I actually think this is
more naturally Perl than "[perl]" in the command string, but it won't
hurt to have More Than One Way To Do It.

> scan_clist is a function like this:
> 
>    sub scan_clist {
>        my($fname) = shift;
>        open (SRCLIST, $fname) || die "Can't open $fname:";
>        while (<SRCLIST>) {
>          chomp;
>        Library $env $libtarget, $_;
>        }
>        close SRCLIST;
>        }
>    }
> 
> Note that scan_clist will be run *during the build phase*, not while
> the Conscript files are being read.
> 
> It's easiest to use Library for this because it's the only command
> which allows adding objects to an existing target.  Since this library
> has a fixed name, and you can have a normal Install rule for it
> (maybe, or maybe you link something else with it, whatever), as well
> as some probably fixed objects you'll add to it.  You also want
> $libtarget to depend on something from the first Command, to make sure
> cons doesn't decide to build it first.  Just use
>   Depends $env $libtarget, $clistfile
> or something like that.
> 
> Hope that helps!
> 
> -- 
> . . . . . . . . . . . . . . . . . . . . . . . . .
> 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