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

[Antonio S. de A. Terceiro]

Olaf Spinczyk escreveu isso aí:
> 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
> >>compile.
> 
> 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.

Yes, that's true.

But gcc (and a C compiler in general) is a core part of any system
itself, which is not ac++ case. At least while people don't design
aspect-oriented operating system. ;-)

> 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.

OK. 
 
> 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.

Debian policies says that source packages must distribute unmodified
upstream distributed source (Debian-specific stuff is generated by a patch).

So, if you (the AspectC++ team) could distribute already-woven sources
as another option when downloading, it would be very valuable.

Even if bigger (how much bigger are we talking about? ;-)).

> >>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 ;-).

Hum ... right.

> >>Again: any plans on using GNU auto* tools? ;-)
> 
> No, not yet.

When (and if) you do, I could (or I would want) help if that.

> Best regards,
> 
> Olaf

Cheers,

-- 
Antonio S. de A. Terceiro <asaterceiro at inf.ufrgs.br>
http://www.inf.ufrgs.br/~asaterceiro