Great summary of the options. On Mon, Jun 2, 2008 at 9:14 AM, "Andreas Rückert" <[EMAIL PROTECTED]> wrote:
> Problem: the c++ module does no preprocessing, so you have to preprocess each > file per hand, before you can import ist. Not so good. > Several options: > > A) try to find an installed cpp and call it. Problem might be to find it, > handle temp > files etc. Make the import somewhat less stable, so I'd prefer an integrated > solution, > that comes with the Argo download. 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. > 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. > C) Use the Antlr cpp grammar to generate our own preprocessor: > http://antlr.org/grammar/1166665121622/Cpp.tar > Problem seems to be, that it's somewhat dated and not so much used/updated > recently. Tried to generate a parser with Antlr 3.0.1, but no luck so far. > Guess the > grammar needs some work. > > D) Integrate a preprocessor into the cpp lexer: > http://www.ibm.com/developerworks/aix/library/au-c_plusplus_antlr/?S_TACT=105AGY06&; > I guess I'd prefer this approach, although it taints the cpp grammar even > more, than > it already is, which make an update to a newer grammar even harder than it > already > is. One workaround could be to convince the Antlr folks, that the preprocessor > should be integrated into the grammar anyway, so they would work with such a > modified grammar in the future. Both options C & D seem to be a lot of work for the benefit, as well as a potential ongoing maintenance headache. 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." 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 All in all, I like Jcpp best, presuming we can get the right license. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
