Re: [A-a-p-user] New to aap: misc. problems

[Bram M. <Br...@mo...>]

Rainer Michael Schmid wrote:

> I am not sure if different tools are used for building a static C and a 
> static C++ library. For the linker, I agree, but for the library? After 
> all, the C++ symbols should be name mangled... on the Mac (and I 
> believe on Linux as well), ar and ranlib are used to build a static C++ 
> library.
> 
> aap seems to use the $LD program to build the static library. I tried 
> to play around by setting the variables, but the main problem by doing 
> this is that aap adds a "-o libmylib.a" for the command (and ar has no 
> -o option). I don't know how to get around this.

OK, thus when compiling C++ for a static library this does not mean the
library has to be build in a different way.  I think we can solve this
by not using the buildaction attribute in the buildlib action.  I'll
rename it to the buildlibaction attribute.  By default it's not set,
it's just for consistency.

> I downloaded the latest version (last week) that was released. So it 
> might be that the fix is not yet in a release. Maybe I will give the 
> CVS version a try later.

I now checked the version log, and this problem was solved in version
1.061.  Perhaps the solution doesn't work for you?  It relies on using
the rule in the default.aap recipe.  Thus if you define your own rule
for compiling it won't work.

> Just a note when it comes to implementing it: on Mac, some libraries 
> need to be specified with -framework, some with -l (haven't figured out 
> yet, what the real difference is, but framework linking is different 
> from the other type of linking...) -- so the implementation should be 
> flexible enough to handle both cases. I haven't seen such a difference 
> on another platform, though.

Well, this basically makes it impossible to write build commands that
are portable to the Mac.  Thus the only solution is to use an "if"
command to have some code specifically for the Mac.  I hate it when
architects make decisions that break portability...

Perhaps we should define another variable for extra linker arguments?
Problem is that the order might matter, thus the extra arguments may be
needed halfway $LIBS.  Simpler would be to define that arguments in
$LIBS that don't start with -l are left unchanged.

> Ok. I will do. I like the base idea of aap and the design so far. Aap 
> seems to be the most promising build tool I have found so far (and I 
> like Python). I don't want to give up using it, just because of some 
> problems.

Please do persist.  I'm sure there are still a few rough edges that need
to be smoothed out.  If we work together we can make it work well.   And
especially don't hesitate to give comments about what could be done
better.

I have uploaded a new version, with the "buildlibaction" change.
Hopefully it works better for you now.

-- 
"I know that there are people who don't love their fellow man,
and I hate those people!" - Tom Lehrer

 /// Bram Moolenaar -- Bram@Moolenaar.net -- 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        ///
 \\\  Buy at Amazon and help AIDS victims -- http://ICCF.nl/click1.html ///