Re: output target locations

Mathew Boorman wrote:

> One goal I am trying to obtain with our build system is a quick
> turnaround on builds on 2 different platforms to check it all build
> properly.  Using :program and library targets with no path component
> will mean a full relink is required after each platform switch.
> 
> Am I missing something?  

The resulting program or library is put in the current directory.
That's because you are supposed to find it under a fixed name, while
$BDIR may be an unknown name from outside Aap.

If you want to produce two versions of the same program or library, you
will have to specify what names they go under.  If a library is only
going to be used from inside Aap, you can put it in $BDIR.  For a
program that's mostly not wanted, since you would have to type
"build-abcdef/program" to execute it.  I often add a "d" for a debug
version, to have both the release and the debug version next to
each other, instead of overwriting one with the other.

> My current solution is embedding $BDIR into each :program, :dll seems a
> relatively complex way to do this, especially once children recipes are
> involved.  I also tried setting a targetprefix but it did not really
> make it any clearer.

This depends on what you are using the recipes for.  It might be a good
idea to set a variable to the name of the program or library:

	bar_lib = $BDIR/bar
	foo_prog = $BDIR/foo

	:child build_the_lib.aap	# uses $bar_lib
	:child build_the_prog.aap	# uses $bar_lib and $foo_prog

Note that the value of $BDIR changes in a child recipe, thus using it in
one child might work differently from using it in another child.

> The philosophy of BDIR seems to be it is used only for object files.  It
> seems to me though that everything should be generated in BDIR.  In
> particular libraries are really just objects anyway.

The idea of $BDIR is that it contains all intermediate results.

If you write a recipe that produces a library to be distributed, then
you want to know where it is from outside of Aap, where you don't know
the value of $BDIR.  Putting final results in $BDIR is inconvenient
then.

> SCons seems to take a very different approach, basically everything is
> built in the output directory, with all source files symbolically linked
> in on the fly as required.  That is certainly a 'scary' solution, but it
> does simplify the recipes by mostly eliminating the BDIR concept. Mind
> you the SCons recipes have a horrible syntax compared with the nice
> format of aap recipes, which is why I'm here :-)

Symbolic links don't work on all systems, especially MS-Windows.

I like many ideas of SCons, but when looking at an SCons script I simply
can't figure out what it's doing without consulting the documentation.
It is so clever that it becomes difficult to understand.  Especially the
use of the "environment" and meaning of strings with "$var" in them.  I
suppose it's because I have worked with Makefiles a long time.

-- 
hundred-and-one symptoms of being an internet addict:
69. Yahoo welcomes you with your own start page

 /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
 \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn