[aspectc-user] AspectC++ self-dependency for compile

Olaf Spinczyk Olaf.Spinczyk at informatik.uni-erlangen.de
Wed Oct 20 12:34:10 CEST 2004

Hello Antonio,

Antonio S. de A. Terceiro wrote:
> Hello all,
> This discussion started at AspectC++ Bugzilla. Lokk at bug #202 for
> further information:
> http://www.aspectc.org/bugzilla/show_bug.cgi?id=202
> As Matthias asked me, I'm posting here my last additional comment there:
>>I realized that I'd need a precompiled ac++, but my point is that ac++
>>*should not* depend on itself to compile.
>>One example of negative consequences of this self-dependency: one of my goals
>>compiling AspectC++ is to package it for Debian. But if we need a non-basic,
>>precompiled binary to compile AspectC++, it we'll be included only in i386
>>architecture, when it could be included in all 11 architectures! And I'm not
>>sure if Debian policies would permit a package with a self-dependency to

it is common pratice that compilers are implemented in the language they 
implement. gcc is also compiled with gcc. Obviously it is no problem to 
have gcc in Debian Linux.

Regarding your practical problems to port Puma/ac++ to a new platform, 
you can work in two steps:

1. On a supported platform: enter the Puma directory and execute "make 
weave TARGET=..."
2. Copy the woven sources to your target machine and compile with a 
normal "make TARGET=...". If the sources are already woven, the make 
file will not call ac++ on the target platform.
3. After compiling the Puma library, compile ac++. Only the Puma library 
uses aspects. ac++ is pure C++ code.

We could also provide the woven sources on the AspectC++ web page, but 
the woven sources are significantly bigger. If there are people who 
regularly want to port ac++ to platforms, which we don't support 
directly, we would do that. We could also send you these sources 
directly to you or even extend our list of supported platforms. Just 
tell us where you would like to use ac++ and we'll find a solution together.

>>What are the crosscuttin concerns in libPuma? Are they important
>>enough to make a self dependencie like that? is they are not
>>functional (regarding libPuma functionality), could they be moved to
>>another Makefile target, e.g.  `make with-debug`, perhaps using the
>>newly-built ac++ to build a special version of libPuma?

g++ and MS VC++ specific language extensions are implemented by aspects 
in Puma. They are not only used for debugging purposes. Without these 
aspects Puma would only be able to parse 100% ISO C++ compliant code, 
which is difficult to find in the real world ;-).

>>Again: any plans on using GNU auto* tools? ;-)

No, not yet.

Best regards,


More information about the aspectc-user mailing list