Re: Converting from Imake!

On Apr 26, 2005, at 3:37 PM, Bram Moolenaar wrote:

>> On Apr 26, 2005, at 2:37 PM, Bram Moolenaar wrote:
>>
>>>> 11) Hierarchical build from top down, or from any of the subdirs
>>>> without issue (preferably without strange command line args).
>>>
>>> You don't need to worry about this, just define what depends on what
>>> and Aap will figure out in what order they need to be build.
>>
>> If I add an "all: libant/libant.a libPromote/libPromote.a" to my
>> toplevel, everything works for static.  But what about my shared which
>> is defined in the main.aap of libant?  Do I have to define every 
>> target
>> twice?  Once in libant/main.aap and once in the toplevel main.aap?
>
> Well, you need to define something.  The simplest would be to use a
> virtual target for each thing you want to build, thus a "shared" and a
> "static" target.  Then the dependencies for them.
>
> If you have lots of these you could do it with a variable argument on
> the command line, such as
>
> 	aap METHOD=static
> 	aap METHOD=shared
>
> And then use an "if" command:
>
> 	@if _no.METHOD == 'static':
> 	   EXT = .a
> 	@else:
> 	   EXT = .obj
>
> 	all: libant/libant$EXT libPromote/libPromote$EXT

This wouldn't handle the case where I would like both built.  Although 
I suppose, I could put a conditional in my toplevel main.aap, but I 
would still have to define the all targets multiple times.

@if _no.STATIC==1
     all: libant/libant.a libPromote/libPromote.a
@if _no.SHARED==1
     all: libant/libant.so libPromote/libPromote.so

That seems kind of kludgy to me, though.  Adding/removing 
directories/libraries would be kind of a pain...

> "In the right order" means there are dependencies.  You should tell Aap
> about them, then it will be taken care off automatically.

True, there are dependencies, but can you define a library being 
successfully built and moved over as a dependency?

> It makes sense.  You appear to want something like a "global virtual
> target", thus one that may appear in every child script.  So that the
> toplevel recipe doesn't need to know about targets in the children.

That's exactly right!   This isn't possible, is it?

I have a SDDAS.aap which I include in all my subdir main.aap files 
(:include ../SDDAS.aap) where I tried defining a global virtual target 
which I called "release".  It seemed like a good idea; however, it said 
"Multiple build commands for target "release""  which is a true 
statement, sort of.  The release command is different for each subdir, 
but similar in nature.  I'm not sure why this fails since "install" is 
in every subdir and that's okay.

The way I currently do it with our Imakes is I do a "make release" from 
the toplevel and it goes to each subdir, doing a make, and then the 
make release, and then moving onto the next directory.  If it fails at 
any level, it stops.  I have an SDDAS.rules which defines all my 
generic rules (like for the release target) and I have variables at the 
top like so:

#define DoNormalLib YES
#define DoSharedLib NO
#define DoDebugLib NO
#define DoProfileLib NO
#define HasMySQL NO
#define OnWindows NO

which tend to make the "rules" do the right thing.  It works so I'd 
like to preserve this aspect.

Cheers,
Joey



-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix