[antlr-interest] Re: 2.7.2 build system is fubar

[Ric Klaren]

Hi,

On Mon, Feb 17, 2003 at 04:21:56AM -0000, Dave <davekam at pobox.com> wrote:
TJP> Oh, you need antlr.jar not antlrall.jar now...

Now they tell me ;P Terence can we put up a fixed 2.7.2 distro after I fix
this in the configure scripts and Makefile build ? (The idea of going
another year referencing ppl to a development snapshot with some essential
fixes does really *not* appeal to me...) Mental note to myself for next
time: do not release when you're about to go on a business trip, do it
afterwards.

> -- if the jar is now antlr.jar and not antlrall.jar, fix the
> references in ./configure.in and scripts/Config.make.in. if antlr is
> required to build itself, then it must be able to find itself. ;)

I'll fix the autoconf build stuff in the course of the coming week(s). The
2.7.2 was released in a period that I had very little time to test stuff
myself. So it slipped through :(

> -- similarly, why then is antlrall.jar still built and installed? if
> you look at my first message, it's several times larger than the built
> antlr.jar. not sure what the difference between the two is.

At a time there was an antlr.jar that was only the runtime needed to use a
antlr generated parser. The all variant was al the junk including the
generator itself.

> -- it's pointless to include the generated *.java files in the
> distribution as readonly, and then try to regenerate new files over
> them. either they should be writable, or not regenerated during the
> build.

This is a packaging error. Our source controll system perforce keeps files
always readonly so my guess is that Terence just tarballed/zipped the lot.
Thus breaking the Makefile build.

> -- on a similar note, it sounds like it's not necessary to recompile
> the jar's just to get the C++ runtime working, but that's what the
> current Makefile does. I haven't tried to make from the lib/cpp
> directory yet.

Submakes should work well as long as configure has run.

> -- make clean should in no case leave the directory in an unbuildable
> state.

There's some bootstrap rules around in the makefile to fix that.

> -- make install should install everything that's necessary. is the
> antlr directory necessary? it certainly appears to be, but I'm not
> sure. just antlr.jar and/or antlrall.jar appear not to be sufficient.

The antlrall.jar and the header files and the libantlr.a files used to be
enough to use the tool. I'll check if this is still the case.

> -- make uninstall should be available.

Detail ;)

> I'd rather be able to build and install the files in standard
> directories and use the wrapper script, rather than changing CLASSPATH
> manually to point to some place my home directory.

The idea in the Makefile setup is to have a antlr script that knows about
the right places to run the tool. Next to it is an antlr-config script that
you can run with the usual --libs --cflags parameters to get the needed
flags for linking/compiling with the antlr runtimes. (I now notice I forgot
a --classpath)

> I also might suggest using the full gnu autotools build system
> (automake, libtool) instead of just autoconf. This should provide the
> proper make actions (build, install, clean, uninstall, etc.) and may
> work properly on more systems. I would do this myself, but I don't
> have the expertise. Any volunteers?

I'm no fan of automake (the support lib used to use automake, was glad to
be rid of it again..) Libtool is plain crap in some setups. It strips out
options I need in my local Solaris setup for instance. And there is no way
to fix this without running every link rule manually with the right
parameters (ever try to make a whole Gnome setup manually and have to run
every link command manually to fix the link stage? Do that once and you
know how I feel about libtool....)

There's no functionality in automake that that is not easily added to the
current Makefile's. Automake will only make it harder for me to maintain
(keeping up with new versions and debugging automake stuff is sheer hell).
So in short I won't do it, and I will not accept patches on antlr to
support it either.

> It may be tricky to get antlr to build well on various platforms with
> the various language it uses, but I know it can be better than this!
> It's frustrating to try to get started when it's in this state.

Main trouble is the dropping of the antlrall.jar which I seem to have
missed. When I'm done it's back to the plain old configure/make/make
install routine, no worries.

Cheers,

Ric
--
-----+++++*****************************************************+++++++++-------
    ---- Ric Klaren ----- j.klaren at utwente.nl ----- +31 53 4893722  ----
-----+++++*****************************************************+++++++++-------
 Why don't we just invite them to dinner and massacre them all when they're
  drunk? You heard the man. There's seven hundred thousand of them. Ah? ..
           So it'd have to be something simple with pasta, then.
                 From: Interesting Times by Terry Pratchet


 

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