[aspectc-user] AspectC++ self-dependency for compile
Olaf.Spinczyk at informatik.uni-erlangen.de
Wed Oct 20 12:34:10 CEST 2004
Antonio S. de A. Terceiro wrote:
> Hello all,
> This discussion started at AspectC++ Bugzilla. Lokk at bug #202 for
> further information:
> 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
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.
More information about the aspectc-user