Re: New to aap: misc. problems

>> - Building a static library with :lib worked fine for a project with
>> pure C files (ar is run and the library works fine). However, I am
>> struggling to get the same thing work for a C++ project: when I first
>> try to build it, the object files are compiled just fine. But when it
>> comes to building the library it tries to do this with g++ and it
>> fails. If I start aap again, no source files need to be compiled and 
>> it
>> tries to build the library with ar and it succeeds. Haven't found a 
>> way
>> to tell aap to do it right the first time.
>
> Why does building with g++ fail?  Or is it just the creation of the
> static library that fails?

It is only the creation of the library that fails.

> On most system it's required to use a
> different linker for C++.  That "ar" is used when no compiling is done
> is actually a small bug, fixed in a later version.

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.

> It appears there is a conflict between using a different build action
> for making a program, and using a different build action for making a
> static library.  A simple solution would be to ignore "buildaction" 
> when
> making a library.  This means that object files from C and C++ sources
> are handled in the same way.  If this needs to be different we could 
> add
> a "libaction" attribute to the object files.

The object files are compiled the same, regardless if they are used to 
link a program or to build a static library. The problem is only the 
building of the static library. This is not done with g++ but with 
ar/ranlib.

>> - I tried to build a C++ program and aap tried to link it with gcc
>> instead of g++. I had to add a {var_LD=$CXX} option to the :program
>> rule.
>
> This should not happen if you compile and link in one go.  As mentioned
> above, there was a bug that this does happen when compiling first, then
> running Aap again to do the linking.  I believe this has been fixed 
> now.
> But I don't recall in which version...

You are right. In my case it was hidden, since I had a :child rule that 
built a library I linked my program against. So what happens is that 
the first, the C++ files of the program are compiled, then the library 
is built and finally everything is linked.

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.

>> - The add_LIBS option passes the arguments (as it seems) directly. 
>> This
>> in my case nice, since I need to specify not only "normal" libraries
>> (with the -l flag), but also some frameworks to link against (done 
>> with
>> the -framework flag). But I wonder why the design decision was to
>> specify libraries via -l and not in an abstract manner.
>
> This is just a convenient way to do it, especially for people that have
> worked with make.  The tool should translate -lxxx to whatever it uses
> to link with library xxx.  But this hasn't been implemented yet.

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.

>> All in all, I lost a bit the confidence in aap and I am wondering if
>> I'm doing something wrong...
>
> I use Aap every day for maintaining websites and checking files into
> CVS.  Compiling C files should also work fine.
>
> The main problem is that Aap isn't used that much yet.  The principles
> work fine, but many of the details, especially in the tools, need to be
> filled in.  If you know how to do something, please suggest fixes.

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.

Rainer



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com