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. --<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... :-( > 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? Ciao, Andreas -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
