RE: Thanks it works, now what

Bram,

Thanks for the answers everything looks good, but I'm still unsure of how to
solve question 1, handling the location of common includes. Ok, I just read
the documentation on startup, but I don't think that quite solves my problem
as it is too global. I will be using "aap" for many disconnected projects
but the startup technique looks to be designed for "site" wide
initialization, I want something "project" in scope.

What I think I want is for aap to look for "family.aap" or
"project_root.aap" starting at the current location "." and use ".." to look
"up" until it finds it. Actually a "function" that was ":hinclude xxx.aap"
might do it. Where ":hinclude" is hierarchical include.

Am I missing something, am I the only person who has this problem? Maybe the
solution is that my model is wrong and I need to change! As always, any
advice is appreciated.


Thanks,

Wink

-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Thursday, October 30, 2003 3:16 AM
To: wink
Cc: [email protected]
Subject: Re: [A-a-p-user] Thanks it works, now what


Wink Saville wrote:

> 1) I want to be able to build any given subsystem without building 
> others, it appears using ":child" and ":includes" allow me to do this 
> but my directory structure is fairly complex and may evolve over time 
> so I don't want children to have to know where the root is. For 
> example in the manual on page 25 the child had the statement ":include 
> ../common.aap". But I'd rather have it something like ":include 
> $rootdir/common.aap" is this possible?

Yes, the name of the recipe to be included can be made with variables. You
could set $rootdir in your startup recipe, for example.  It's flexible
enough to do it the way you prefer.  I would use a name like "vimrootdir",
you could have several projects.

If you split up the project in pieces then using ":child" should work well.
Each child can be build separately, or you can build the whole "family".

> 2) In "Chapter 9. More Than One Recipe" the main.aap at the root had 
> the ":program" statement, but since I'm going to making lots of 
> different things, I don't want the "$rootdir/main.aap" to know what is 
> being made I just want it invoke each of the children and let the 
> children build what there suppose to. How can I do this?

It depends on what you want to build.  If it's a program then you can use
":program".  If you are building intermediate results you could pass the
name of the result back to the parent with $_parent.result.

You can always fall back to explicitly specifying dependencies, like you do
with make.  Commands like ":program" are shortcuts.

> 3) I assume $rootdir/main.app will have to know the order to build 
> things, i.e. libraries will have to be built before users of the 
> libraries or is aap smart enough to know how to do this?

This should happen automatically.  Just specify the dependencies and Aap
will figure it out.

> 4) I'm going to be using ARM ADS1.2 compiler I assume I'll need to 
> create an "armads1_2.py" modeling one of the tools/*.py files, which 
> should I use as a base? (Note I'm a C/C++ programer and no nothing 
> about Python but willing to learn:)

It depends on what kind of arguments the compiler takes.  If it's mostly
standard C then you might be able to do it with $CFLAGS and other variables.
Otherwise browse the tools/*.py files and looks which one matches your
compiler best.

> Thanks in advance, hopefully if I'll be able to use aap and makes some 
> contributation back to the cause.

Note that Aap is open source and being developed, thus if there is something
that doesn't work it could be added.

-- 
An indication you must be a manager:
You can explain to somebody the difference between "re-engineering",
"down-sizing", "right-sizing", and "firing people's asses".

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