Quote:

Yes, definitely.

Quote:

No plans at the moment. But I would like to support 68k as well (and OS4). What is the most convenient solution for doing that? WinUAE?

Quote:

Many thanks! May I include it in Icaros Desktop as replacement of AROS installer? And, by the way, are you planning to build it for 68K too? It would be an awesome addition, since by now I have to replace the AROS installer on 68K with a improved version of Commodore installer which has been freely available on aminet for years, but it is in a grey area from the legal standpoint. Your installer would greatly fix this issue as well.

Thank you, Alpha 27 is already available on Aminet ;)

http://aminet.net/search?query=InstallerLG

Quote:

No, I'm not doing anything with it right now. You could always get the latest version from here if Aminet is unavailble:

InstallerLG on Sourceforge

Hi. I can't download InstallerLG from aminet ("sorry, forbidden"). Are you updating the new version?

Nope, doesn't hurt. I'll include it in the next release.

i think it doesnt hurt to include it for aros users who compile their stuff. do you?

@wawa

Yes, the mmakefile is not a part of the Aminet archive, it's on GitHub only. If you like to have it on Amnet I can include it the next release (which will be pretty soon, < a week).

@sTix
sorry, i havnt had yet time to look at it and we are having some debate, as of if and how would that need to be incorporated, but have you stripped the aros mmakefile from the aminet release?

@wawa: I know it. In fact and as I was saying before, the generated parser should be compilable from any system, included an Amiga/-like one.

The point is that both YACC and ANTLR take a source (written in their one meta-language) and generates a parser, which is the one which is interesting and used finally.

So, a build system can just take such already generated parser and compile it, without requiring other big dependencies, like using Java.

The build system can also be configured to first use YACC/ANTLR to get the parser source, then generate the parser, and after that compile the generated parser. This clearly doesn't work in an Amiga/-like system.

So, for a developer it's better to commit both the parser description and the generated parser, in order to avoid such dependencies. Which makes sense, because you don't continuously change the grammar of the language.

I hope that it's clear now.

P.S. Other than the simplicity and easy of use writing grammars, ANTLR has a couple of other benefits.

First, with its language is it possible to define both the lexer, the parser, and the AST parser. With other tools like YACC you can only create the parser, and need other tools to create the lexer (like LEX) and the AST parser (usually this is written by hands).

Second, ANTLR already supports many different programming languages. It means that there's already support for C/C++, Pascal, Python, etc., whereas YACC is written to generate C/C++ parser, and if you want to generate parsers for Pascal, etc., you have to search around and see if someone has ported or created a YACC version for the specific language, which might have differences from the original. In short: ANTLR is already ready (!) and officially supports many languages.