Andreas Rückert wrote:
Hi!
-------- Original-Nachricht --------
Datum: Mon, 2 Jun 2008 10:30:13 -0400
Von: "Tom Morris" <[EMAIL PROTECTED]>
An: [email protected]
Betreff: Re: [argouml-dev] C++ module preprocessor
--<snip>--
This is more work for the user and little messy, but I don't see any
particular reason it should make things less stable. It has the
advantage that it will be using whatever preprocessor the user
normally uses.
Yup. And we have to figure the name and the path of the preprocessor,
potential options etc. I'm sure we'll get complaints, that the C++ import
doesn't work, just because the CPP called failed, and the user doesn't
realize, that he has to give Argo the required info to call the preprocessor
properly. An integrated solution gives us more control which is usually
better. We already know exactly how to call the preprocessor at Argo
build time.
B) Integrate some preprocessor written in Java into Argo:
http://www.anarres.org/projects/jcpp/
Problem here is the license (GPL(2)) and the integration of foreign code
into Argo
(to some degree).
The author says that he's liberal about granting less restrictive
licenses on demand. Why not ask for a LGPL license for us? If he
agrees, that should solve the problem since we distribute other LGPL
binaries already.
I don't know anything about the quality of Jcpp, but if it's
reasonable quality, this would probably be my first choice with option
A above being my second choice.
The anarres server already seems to be slashdotted, so I got the sources
from here:
http://linux.softpedia.com/progDownload/jcpp-Download-26034.html
Ok...on jcpp...
It does full lexing of the sources, and wants to avoid relexing, so it doesn't
give you an output stream, but defines a PreprocessorListener (that's a
class, but rather should be an interface), that gets the tokens.
You can get the text of the preprocessed file via concatenating token.getText().
In a way, JCPP's concept is to integrate the compiler's lexer API into the
preprocessor. Like option D, but the other way around.
I'd rather like to keep preprocessor and our import more separated, and just pass
some piped outputstream to the preprocessor, attach it to some piped import
stream,
that we use for the import and just call some sort of run() method.
This is in my watch list for a while, but, I was first focused in
getting the whole C++ generation and reveng into a state that it would
work more correctly without the preprocessor step. But, if someone has
enough bandwidth to tackle it this would be the approach I would more
enthusiastically support. I don't know exactly why (from a technical
point-of-view) I prefer it, but, separation of concerns, library reuse
and expectable lower maintenance adds up.
--<snip>--
Both options C & D seem to be a lot of work for the benefit, as well
as a potential ongoing maintenance headache.
You are right. If David would still maintain the C++ grammar at Antlr, we could
try to ask him, if he want's to add this features, but as it stands, noone will
maintain that grammar in the near future anyway, so I guess we can forget this
option now... :-(
Yeah, I saw somewhere (don't know exactly where) that David was asking
for volunteers to maintain it after his last update of the grammar. One
thing that is missing is to update the existing ported grammar in
argouml-cpp to the latest version available in the ANTLR site.
For example the article
in option D closes with "Although this article doesn't deal with
potential errors and error-handling strategies, a real-world
preprocessor must account for these factors; for example, the ordering
of tokens in conditional macro processing is significant, and you must
take steps to ensure that it's handled correctly."
Well, if the includes would work, we'd already be a lot further. The whole C++
import is incomplete anyway, so if we could find all the classes, vars and
methods
for now, that would be ok. We don't have the sources for roundtrip engineering,
so if we cannot parse any sophisticated macros in the method bodies, I could
live with
it...
I'm not sure if this is the same as the grammar in option C, but it
was linked to from the IBM article
http://www.antlr.org:8080/pipermail/antlr-interest/2004-July/008778.html
No, the latest preprocessor is from 2006 and a different author...it already
uses some Antlr 3 features, but seems to rely on the tokens from 2.7, or so...
I was somewhat confused by the used classes in this grammar, and tried some
combinations of Antlr 3 CC and Antlr 2 libs, but couldn't get it to work yet.
All in all, I like Jcpp best, presuming we can get the right license.
So, should we ask him? What do the other developers think? Linus? Luis? Bob?
Please do :-)
Luis
Ciao,
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
