Re: Cross-dependencies and output folders and more

Dobes Vandermeer wrote:

> Most likely I'll want some toplevel commands in the main.aap that say
> something like ":do cptobin server" and ":do cptolib libXXX.a" so that
> these will always happen, regardless of whether I run aap test or aap
> install.  That way I can do manual tests without running the automated
> tests.

It's possible, although the "right" way would be to have the manual
tests depend on the files they use.

> > 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.
> 
> Thats close; but the grist would also include your variants and the
> current project (usually named after the subdir) so that you can tell
> one object file from another with the same name.  As I've said, without
> the "LOCATE" and "SEARCH" feature, the grist might as well be the output
> folder, since the output folder is pre-determined anyway.

$BDIR also includes the variant and other things that require the
object file be placed somewhere else.  But if you mean that you can have
one file that is overwritten when compiled with different arguments then
you are right that this is not included in this solution using a
variable name.  You would also need to specify those different arguments
additionally.  For me that's actually better, since it's simpler and
more explicit about what will happen.

> > Including $BDIR in
> > the target would be possible, so long as we can avoid the shell from
> > expanding it.  This would work on Unix:
> >         aap '$BDIR/foo.o'
> 
> Could work; to be honest, though, usually in jam I avoid typing the
> grist on the command line anyway (since < and > are shell characters)
> and define special targets inside the build file, like:
> 
> Depends install_XXX : <installed>XXX ;
> 
> And type "jam install_XXX".  This is where grist is handy, because I can
> distinguish the installed version from the other version.  On the other
> hand, its probably not that much effort to compute the actual output
> path of <installed>XXX and but $INSTDIR/bin/XXX or whatever in that
> special rule.
> 
> This grist is a technique thats only really useful in conjunction with
> SEARCH, where you specify a search path for a file and then refer to it
> only by grist and name.  If the paths aren't bound late, there's no
> advantage.

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

> > These requests are not exotic.  I think Aap should be able to support
> > this.  And I don't see a reason why it couldn't, thus it is only a
> > matter of someone implementing this.  Actually, the implementation is
> > probably simple, the main work will be to decide how to specify a
> > project with sub-projects in a nice, simple and reliable way.
> 
> Yes, definitely.  Isnt that always the hardest part?

Thinking of a nice, simple and reliable solution?  Yes, often that's
difficult.  It requires having a clear view on what the goal is, I think
we more or less have that now.  Next step is to think of possible
solutions and check if they have any problems.

> A good case in our system is when I turn on detailed memory tracing
> using -D command line switch and then the entire tree has to be
> rebuilt.  When I'm done I've usually changed just a few files and I
> switch back -- now the entire tree must be built again!  In jam, this
> means running jam clean because files dont depend on their command
> line.  I do have different object output folders right now for release
> vs debug builds, but it would be cumbersome to implement another one for
> each variation of debugging defines.

Well, that's one thing that Aap will do "the right way" for you
automatically.  Although Aap doesn't have a limit on how much space
rarely used variants use up.  But with prices of harddisks these days
that is mostly not worth worrying about.

> Well, javac allows cyclic dependencies, and no intermediate file is
> generated to support this -- you just have to pass both files on the
> same command line.  Also, javac may emit multiple class files per java
> file, so if you wanted to copy those files around you would have to be
> able to predict where they were going to end up.
> 
> Our current approach is to not allow cyclic dependencies between jar
> files (a reasonable approach) and then build all the class files for a
> jar, and the jar itself, at once.  This is doable and you can make the
> jar file depend on all the source files.  The problem is with the
> intermediate files -- if you keep them, then if you delete or rename a
> class its class file wont be deleted.  If you delete the class files
> then your builds are much slower :(
> 
> Thats one of the annoyances about jam I forgot to mention:
> 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.

This mechanism does work for CVS: source files no longer used are
deleted from the repository.  I'm using this for the Aap files itself.

-- 
"The future's already arrived - it's just not evenly distributed yet."
		-- William Gibson

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///          Creator of Vim - Vi IMproved -- http://www.Vim.org          \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/