[antlr-interest] Re: antlr 2.7.2 release candidate 2 available

micheal_jor <open.zone at virgin.net> open.zone at virgin.net
Wed Jan 8 01:36:10 PST 2003


--- In antlr-interest at yahoogroups.com, Terence Parr <parrt at j...> 
wrote:

> I don't like having to download yet another tool just to build 
> something (e.g., Ant or python).  Further, XML should not be used 
for 
> human consumption (e.g., Ant).

You may be right but, I use Nant, rather lazily I might add, for the 
C# build requirements because it solves that problem rather nicely. 
For the examples, I use it to build the executable and then run a 
simple test using a supplied sample input file (I should probably 
make it check that the runtime library has been built first). I also 
supply a VS.NET project file for the library itself [I might add a 
project file for #Develop too].

My rationale is that most .NET shops know of and, indeed, have NAnt. 
It is a familiar tool, used in a familiar way within ANTLR-C# to 
address the build problem - a familiar problem.

> What I want is a stupid build script 
> that just compiles everything and then jar's it up.

I use Windows batch files for building the java bits simply because 
there isn't an Ant build script for ANTLR itself [I should probaby 
just write one or incorporate one of the many contributions that will 
pour in once this post hits the list ;-) ].

> When it only takes 
> a few seconds to rebuild the whole 50k line program, why on earth 
would 
> we bother with dependencies and other junk.

Because we can do so much more than just compile the source files 
with this infrastructure -- and we can do it portably. We can run 
standard tests when we have them, build and package ANTLR's runtime, 
debug and full (including source) distribution archives, invoke ANTLR 
on itself whenever included grammar files such as anrlt.g, and 
XXX/action.g are updated etc.

Basically, we can specify and codify the knowledge required to do 
this tasks unamiguously in the build scripts - once only and in one 
place - and never have to tend to them again until we need to change 
them. Of course a lot of this would be even more powerful if we can 
extend ANTLR itself with the ideas about inheritance, cleaner 
dependency handling etc that floats through this list every once in a 
while.

My only regret is no freely available, widely used tool seems capable 
of addressing the diverse requirements of Java, C#/.NET and C++ build 
issues simultaneously. Until then, we have Ant, NAnt and [N]Make. 

And your new tool for those that just can't wait to get it on with it 
ANTLR  ;-)


Cheers,

Micheal



 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 



More information about the antlr-interest mailing list