Re: Cross-dependencies and output folders and more

Bram Moolenaar wrote:
> 
> Dobes Vandermeer wrote:
> 
> > > It could be useful.  For example, Aap already uses
> > > the $BDIR variable for the directory of the object files.  You wouldn't
> > > want to use its value on the Aap command line.  In Jam terms you would
> > > have a target $BDIR/foo.o called <bdir>foo.o.
> >
>
> $BDIR also includes the variant and other things that require the
> object file be placed somewhere else.

Er.. yes.  I suppose I interpreted you example as being literally
<bdir>foo.o, rather than <$BDIR>foo.o.  That way multiple variants of
the same file will have different names in the dependency tree.

> I see.  It seems that this means there is even less reason to add this
> feature to Aap.

Yes, indeed.  I wasn't really suggesting it, just explaining it in case
you cared.

> Well, that's one thing that Aap will do "the right way" for you
> automatically.

Yeah, thats one of the things I really like about it.

> > If you delete a source file, its not removed from the libraries/jars it
> > is in, its intermediate files aren't cleaned up, and so on.  You have to
> > clean it out by hand.  Would be nice to have a build system that
> > "remembered" what was "in there" and cleaned anything out that
> > disappeared.
> 
> Although Aap does remember what was build in the past, there currently
> is no mechanism to have a "clean" use this information.  I have been
> thinking about this, but without an actual implementation popping up
> yet.  It's also very useful for uploading files: you want to delete
> files that should no longer appear on the server.

Really these files should go away no matter what target I build -- they
have become completely useless and undesirable.  Also, since LIB is
incremental, I need to be able to remove them from the LIB file
(possibly by doing a non-incremental build when something is removed).  

I suppose the easiest way is to store the the previous inputs to the
action and compare which were added or removed.  This will solve half
the puzzle -- at least you can do a non-incremental build when the
removed list is non-empty.  

Actually removing unneeded object files is a slightly different story,
because you'd want to handle the case where one object file is used by
multiple binaries (rare though this may be).  In that case you'd have to
store a total list of all files that were built by aap, and then compare
that to all the files aap wants to build now.  Any missing files can
then be deleted.  The list would have to be variant-specific, and I'm
assuming files aren't ever the same between variants.

CU
Dobes


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/