Re: Cross-dependencies and output folders and more

Dobes Vandermeer wrote:

Phew, lots of questions.  Most of them don't have a clear "this is how
you do it" answer.  There are many ways to do something, and which one
works best depends on your situation.

> I want to build my system, which is structured like this:
> 
> Libs/expat - Build a lib file
> Libs/tomcrypt - Build a lib file
> Libs/Utility - Build a lib file
> Libs/ProtocolHandler - depends on Libs/Utility, Libs/tomcrypt,
> Libs/expat
> windows/ShellExtension - depends on Libs/ProtocolHandler and the others
> by proxy

How do these dependencies work exactly?  If it's a dependency on the
generated library itself it could be simple.  This also depends on
whether you want to be able to build each library separately, or just
build everything from the top.  Being able to build each part separately
is more complicated.

> The output binaries used for testing have to simulate the installation
> tree because the binaries use their own location to find their
> configuration & the jar files.  The installer builders we are using are
> somewhat restrictive about where they will get their files from, so we
> want the install folders to be specially laid out.

That sounds complicated.  If runtime files matter I mostly prefer to do
testing after installing into a temp directory, so that it works exactly
like a real install.  That means you also test the install procedure
(not forgetting a file or putting it in the wrong place).

> We currently use Jam, and its "grist" feature was worked out very well,
> because we can have multiple targets with the same filename but a
> different "grist".  
> How is this done in aap?  
> Would I use :publish or :install?  And if so, can I have this done even
> when not running 'aap install'?

What does "grist" mean?  I looked at the Jam docs but it's not clear to
me how it works.  In Aap you can have real targets, which are identified
by the file name, and Virtual targets, which can be anything.  I don't
see how you can have multiple targets with the same file name, they
would overwrite each other.  Or do you mean targets in different
directories or with different variants?

If it's about making sure that files in the right place for testing then
the simplest solution is often to simply copy the files with ":cp".
Doing this with dependencies can be uneccessary complicated.

> How should I handle the cross-tree dependencies?  We I use:
> 
> Libs/ProtocolHandler/main.app:
> :include {once} ../expat
> :include {once} ../tomcrypt
> 
> Or maybe:
> :child ../expat
> :child ../tomcrypt

For dependencies you should use ":child".  But this is normally used from
the parent recipe in the top directory.  Apparently you want to build
the ProtocolHandler by itself, and make sure the libraries it depends on
are build first.  Although ":child ../expat" will work, this will cause
trouble when building everything.  Hmm, apparently Aap doesn't handle
this yet.  It would require a bit of Python:

	:if has_target("expat_library_name") < 1:
		:child ../expat.aap

This isn't nice, and I can understand that this is a normal situation.
I'll have to think about a nice solution.  You really only want to
specify the dependencies between libraries once, and don't want to worry
about including the right recipes in each sub-project.  That would mean
going back to the toplevel recipe, while still only building the
sub-project somehow...


> In our jam system, we have some top level files, Jamrules and
> Jamrules.local, that allow us to specify useful variables and build
> actions.
> 
> In aap, you seem to be recommending that we put:
> 
> include ../../common.aap
> 
> Since we know every file will have exactly the same line, couldn't we
> imply insert that line?  In jam, you say:
> 
> SubDir TOP Libs expat ;
> 
> And it reverse-engineers the location of Jamrules and loads it.

You can use $TOP, but that won't work if you only build a sub-project.

> SCons is even better -- it searches upwards for the top build script for
> you, and loads it.  

There have been ideas to add something like this to Aap.  It hasn't been
implemented yet.  A disadvanage of SCons is that it's too easy to end up
using the wrong build script without a warning.

> Does aap have any kind of automatic tree detection?  It would be great
> if I could omit not only the :include ../../common.app, but also any
> lines for cross-tree dependencies (other than a line saying that this
> executable links with that library, or this library uses that library so
> link that one if you link this one).

Currently it only works if you build from the toplevel.  I agree it
would be nice to add support for building sub-projects and still use the
dependencies that were defined at the toplevel.

I think currently you can only do it comfortably when building
everything from the toplevel, specifying the sub-project you want to
build.  Thus something like:  "aap  ProtocolHandler"  and then make the
virtual target ProtocolHandler build the sub-project.  Since all
children are specified at the toplevel, a dependency somewhere down in a
sub-project would still work.

Flaky example:

	main.aap:
		:child lib/one/main.aap
		:child lib/two/main.aap
		one : lib/one/libone.so	  # make "aap one" build libone.so

	lib/one/main.aap:
		libone.so : one.o ../two/libtwo.so
			:do buildlib $source


> Some of my source code is generated as part of the build process, and
> the generator is also built in the build tree.   How do I tell aap how
> to run my tool to generate those source files?  Is it ":action build
> <whatever> ?"

Just specify the dependencies, e.g. (sketchy):

	file.c : file.c.in  generator
		:sys generator <$source >$target

	generator : generator.c
		:do build $source

Aap will build "generator" before invoking it, when necessary.

> With Jam, I can specify new rules, like "MakeNSISInstaller".  I can
> apply this rule to build multiple different installers with different
> input and output files.  Can I create an equivalent ":makensisinstaller
> xxx : yyy" in aas?  Or how is this meant to be done?

It depends on what kind of rule you want to make.  You can use a ":rule"
if you want to match the file name with a pattern.  But you probably
want to use ":produce".  Alternatively, you can use actions, since they
are selected on file type.

> BTW, these might make good FAQ entries (even if they are in the
> documentation); I'm probably not the only one.
> 
> I'd like to use aap for my project, but I'm not a Python programmer
> (yet) so I can't really hack it up to add these features if they aren't
> there.

Your project sounds like a quite complicated one with specific demands.
You probably run into a few things that have not been implemented yet.
First thing is then to find out what you actually wanted to do before
thinking of possible solutions.

-- 
The MS-Windows registry is no more hostile than any other bunch of state
information... that is held in a binary format... a format that nobody
understands... and is replicated and cached in a complex and largely
undocumented way... and contains large amounts of duplicate and obfuscated
information...  (Ben Peterson)

 /// 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/