A N T L R 
======================================================================

 Contents of this files is about  i n s t a l l i n g  ANTLR. If you 
 want to get some general information please checkout file  
  
                         README.txt

 which is part of this package. You may als visit "doc/index.html" for
 further information as well as http://www.antlr.org in general.

 If you want to know about the very basic steps on  u s i n g  ANTLR
 then have a look into section  

             ANTLR IS INSTALLED - WHAT'S NEXT?

 in file README.txt or in this file.  You may also follow a simple 
 mini-tutorial at

      http://www.antlr.org/article/cutpaste/index.html

 You may want to checkout also some target specific information on how
 to use ANTLR. Take a look at:

     doc/index.html           - main entry for all documentation 
     doc/runtime.html         - when using JAVA 
     doc/cpp-runtime.html     - when using C++ 
     doc/python-runtime.html  - when using Python
     doc/csharp-runtime.html  - when using C#

 If you don't have a precompiled version but rather a source code dis-
 tribution and you want to know some details on how to build and inst-
 all then you have come to the right place,

                          PLEASE READ ON

 Otherwise please skip this document! 
 

----------------------------------------------------------------------
TABLE OF CONTENTS

 * WHERE CAN I DOWNLOAD ANTLR?
 * REQUIREMENTS? 
 * BUILD AND INSTALL? BRIEF VERSION! 
 * BUILD AND INSTALL? LONG  VERSION! 
 * ANTLR IS INSTALLED - WHAT'S NEXT?
 * BUILD AND INSTALL ON WINDOWS NT/95/98/2000/XP?
 * FURTHER DETAILS ON ANTLR'S BUILD SETUP?
 * FAQ?
 * LIST OF CONFIGURED VARIABLES?
 * PLATFORMS?

______________________________________________________________________
WHERE CAN I DOWNLOAD ANTLR?

 ANTLR can be obtained from http://www.antlr.org either as
 
  * precompiled binary (RPM, MSI installer etc) 
  * source distribution (tar + zipped)

______________________________________________________________________
REQUIREMENTS?

 To get most out of ANTLR you should build ANTLR on UNIX or UNIX like 
 system. For example,  you need a bourne shell and a couple of common 
 UNIX tools like "grep", "mkdir", "cp", "rm", "sed", "cat" and "chmod". 
 
 You need also a GNU make or compatible make.

 Such a ANTLR friendly eco-system is given on Windows by having CYGWIN
 or MSYS installed. An out-of-the-box Window system may will  not work 
 for installation. 

 If you want to know on which systems ANTLR has been developed, which
 systems are known to work and known  to  fail  then please move your
 cursor down near the end of this document.

______________________________________________________________________
BUILD AND INSTALL ANTLR? BRIEF VERSION! 

 Here's a very brief summary of how to build and install ANTLR.
 
   $ cd $HOME
   $ gzip -d -c antlr-x.y.z.tar.gz | tar xvf -
   $ cd antlr-x.y.z
   $ ./configure --disable-examples
   $ make install

  Of course you can unpack ANTLR wherever you want on your machine -
  given enough space and permissions. For simplicuty, I'm just using
  $HOME and this may work for any user.
 
  ANTLR's source distribution contains lot's of examples. Making them
  can be quit longish. You may want to skip those examples if you are
  just interested in  building the core libraries. Note that examples
  are not installed.

  Python users: Note that "make install" will not add antlr.py to your
  local Python installation. This needs to be done manually by you. To
  simplify this you may the script "pyantlr.sh". Checkout this  script
  in directory "scripts" or, when installed, in directory "sbin".
 
______________________________________________________________________
BUILD AND INSTALL ANTLR? LONG VERSION! 
 
 This section presents details on the build process.

 1. Unpack
 =========

 To  build  ANTLR you need to unpack ANTLR's source distribution. This 
 will create a new directory named antlr-x.y.z in your current working
 directory. Typical unpacking steps are:

   $ cd $HOME ; 
   $ gzip -d -c antlr-x.y.z.tar.gz | tar xvf -

 Here I'm unpacking ANTLR in my $HOME directory but you may unpack in
 any directory that suits you. If you have gnu tar, then you can use 
 the simpler

   $ tar xvfz antlr-x.y.z.tar.gz

 to unpack the distro.

 For the rest of this document I will use ${srcdir} as a place holder
 to name the directory containing ANTLR sources. In the example given
 above, the following would be true:

   srcdir == $HOME/antlr-x.y.z


 2. Build Directory 
 ==================
 Create a build directory and change into that directory. A build dir-
 ectory can be any directory on your system. In the very brief version
 shown above I'm using the source directory -- ${srcdir} -- as build 
 directory. However, the general way and also the better approach is
 to use a new, fresh and clean directory. If at any later stage some-
 thing goes wrong you can just remove the whole build directory and 
 start from scratch again. You can also have ${srcdir} in read-only
 mode as no files are touched or changed with this approach. This is
 not the case if ${srcdir} and build directory are equal.

   $ mkdir -p $HOME/tmp/antlr
   $ cd $HOME/tmp/antlr


 3. Configure 
 ============
 
 Building ANTLR is accomplished by the well known GNU autoconf/make 
 approach. That is  you  run  a  shell script to create specialized
 files -- usually Makefiles -- for your particular environment.

 Within the build directory run configure like


   $ ${srcdir}/configure  --prefix=${installdir}


 where ${srcdir} points to your package directory (see step 1).

 Option --prefix==${installdir} tells configure where you want to
 have ANTLR installed on your system. Using this option is not
 mandatory. If you are not using it then configure will use 

       "/usr/local"

 as default installation directory. That  is  binaries will be 
 installed in /usr/local/bin, libraries go into "/usr/local/lib" etc. 

 Note that "configure" will search your $PATH for command line tools 
 to compile Java, C++ and C# source code, execute Python etc. This  
 behaviour of configure can be changed by using command line options 
 and/or environment variables. 

 To see a list of available configure options just run
       
       ${srcdir}/configure  --help 
   


 4. Build
 ========

   $ make

 This will (hopefully) build all needed ANTLR libraries within the 
 "lib" directory. If something fails for your system, and you want to 
 submit a bug report, you may wish to include your "config.status" 
 file, your host type, operating system and compiler information, 
 make output, and anything else you think will be helpful.

 If "make" complains about unknown rules etc. then it's usually 
 because you are not running GNU make. Configure will search for a GNU
 make in $PATH and in some well known locations.  If  there's  no  GNU
 make on your system, then configure will report an error in step 3,
 otherwise the first suitable GNU  make  wins.  However, if configure
 detects that "make" is not identical with the found one, configure 
 will show a reminder message as last action. The reminder message 
 will then tell you which make your are supposed to use.



 5. Test
 =======

 You may also wish to validate the correctness of the new ANTLR by
 running regression tests. It will makes you very confident if all
 test run through:
 
   $ make test

 However, please don't panic if a test fails. In most cases it is
 rather a problem  of running the test itself than a problem with
 ANTLR. When sure about a bug let us know please. Be sure to include
 information on your system, the ANTLR version used and other relevant
 information.

 

 6. Install
 ==========

 Depending on your ${installdir} directory you may need to have
 write permission to copy files. If you gained permissions required --
 perhaps by becoming super user -- install ANTLR by


   $ make install

  Python users: Note that "make install" will NOT add antlr.py to your
  local Python installation. This needs to be done manually by you. To
  simplify this you may the script "pyantlr.sh". Checkout this  script
  in directory "scripts" or, when installed, in directory "sbin".
   
 7. Clean
 ========

 Having installed ANTLR it is save to remove source and build 
 directory.

 
 8. Enjoy!
 =========

______________________________________________________________________
ANTLR IS INSTALLED - WHAT'S NEXT?

 Please read "doc/getting-started.html" on what you are supposed to
 do. Here's a very brief summary for the impatient:

 ANTLR is a command line tool. To run ANTLR you need to have JAVA
 installed. The basic steps are:

  a. write a grammar file - mygrammar.g

  b. run ANTLR like

       $ CLASSPATH=<path-to>/antlr.jar

       $ java antlr.Tool mygrammar.g

  c. write a driver program using source code generated by ANTLR, ie.
     Main.java, main.cpp, Main.cs or main.py

  d. link generated code, your driver code, ANTLR's core library and
     any additional library you are using together to get an 
     executable

  f. run the executable on arbitrary input to be parsed

 For a set of standard examples have a look into directory "examples"
 and appropriate subdirectories. You may want to run make like

  $ make verbose=1

 to see which compiler is used and which flags are passed etc. You may 
 also follow a simple mini-tutorial at

      http://www.antlr.org/article/cutpaste/index.html

 if you are absolutly new to ANTLR.

______________________________________________________________________
BUILD AND INSTALL ON WINDOWS NT/95/98/2000/XP?

 There  is no difference in building and installing Windows. However,
 you are need have either Cygwin or MSYS installed. We haven't tried
 MKS yet.
 
 If you run configure with Cygwin (or MSYS) then gcj will usually be
 chosen for compiling Java and gcc for compiling C++. In most cases
 however, C# will be  automatically disabled as no compiler can be 
 found. 

 Configure is not looking up the registry to check for installed soft-
 ware. Instead, configure will just check the $PATH for known compiler
 names and also check some well know locations like "/usr/local/bin"
 etc.

 In order to make configure aware of a certain compiler or tool you
 need, make sure that your compiler or tool can be found by looking up
 $PATH. For example, Microsoft Visual C++ comes with a batch file 
 named vcvars32.bat. Just run this batch file prior of running bash to
 have "cl" in your $PATH.

 Configure knows about this compiler names:

   bcc32 cl g++        for C++
   jikes javac gcj     for Java
   csc mcs cscc        for C#
   python              for Python
   
 The order in which the names appear is also the  search order. That
 means that the whole $PATH gets searched for bcc32, then for cl and
 finally for g++.

 In  other  words, it is sufficient to have "cl" in $PATH to have it
 selected by configure, regardless whether there is g++ available or
 not. Similar, if you also have bcc32 in $PATH, then the Borland C++
 Compiler will be choosen.

 If you have more that one compiler in your $PATH and the "wrong" 
 compiler is selected - Do you have to give up on this?

 Not at all.

 In case you have more than one compiler/tool in your $PATH, you can
 tell configure which one you like to have. For example:

  --with-cxx=g++

 This  will favor g++ regardless whether there's a cl or bcc in PATH.
 You can archive the very same by

  CXX=g++ ${srcdir}/configure 

 That is by using an environment variable. Try --help for the full
 list of --with-xxx options and environment variables.

______________________________________________________________________
DETAILS ON CONFIGURE?

 This section will present some further details on how you can tell
 configure to behave the way you want:


 1. Choose Language
 ==================

 ANTLR is implemented in Java and has code generator plugins for Java,
 C++, C# and Python.

 The default behaviour of configure is to check whether a suitable
 compiler or tool for a particular language is available. If not, then
 configure will show a warning  message and will automatically disable
 support for this language.

 In a very bizarre case it  is  therefore  possible  to end up  with a 
 configuration with no language support at all. Please study therefore
 configure's output whether you end up with the system you want.

 On the contrary, configure will enable, as mentioned, every target
 language with sufficient compiler/tool support. To speed up the 
 build process you may also disable languages (and configure them
 later again). This can be done by command line options:

  --disable-cxx    | --enable-cxx=no        --> disable C++ 
  --disable-java   | --enable-java=no       --> disable Java      
  --disable-csharp | --enable-csharp=no     --> disable C#
  --disable-python | --enable-python=no     --> disable Python

 Be warned that when disabling Java you can't even build ANTLR itself.
  
 
 2. Be Verbose
 =============

 A typical 'make' run  reports all kinds of actions exactly the way 
 they  get  carried out. This makes the output of a make run hard to
 read and it's difficult to keep track "where" make is right now and
 what's going on.

 ANTLR's make run has been designed to be readable. By default make 
 will report what's going on in a kind of logical way. For example,
 when compiling ANTLR itself you will see a message like

  *** compiling 209 Java file(s)

 This information is usually enough to keep track what's going on. If
 compilation fails, then the exact command line causing the problem 
 will be shown and you can study the arguments whether additional
 flags are required etc.

 However, you can tell configure to be verbose as usual by

 
  --enable-verbose


 Having enabled verbosity, the command to compile ANTLR will be shown
 similar like this (using javac):
   
  CLASSPATH=
  /opt/jdk32/142_03/bin/javac \
     -d . \
     -sourcepath /home/geronimo/src/antlrmain \
     -classpath /home/geronimo/obj/antlr-linux/lib/antlr.jar \
     Version.java \
     ANTLRParser.java \
     ...
     [[skipped 206 files]]
     ...
     /home/geronimo/src/antlrmain/antlr/debug/misc/JTreeASTPanel.java


 You have used --enable-verbose and output is too much. Do I need to
 configure again?

 No. Just run make like

  $ make verbose=0

 to turn off verbosity for this make run. You can also do this

  $ verbose=0
  $ export verbose
  $ make

 to turn verbosity off without using arguments to make.

 Of course, you can also turn verbosity on (verbose=1) in the very same
 way, regardless of what you have configured earlier.


 3. Debug Version
 ================

 A typical open source configuration sets compiler options to contain
 debug information.

 ANTLR's approach  is  a  bit  different. We believe that you want to 
 u s e  ANTLR  and  not to  d e b u g  it. In other words, we believe
 you are voting for speed.

 Therefore configure will set compiler flags that go for speed and we
 omit all flags introducing some debug information. 

 If you need to go for debug information, turn those flags on by using

  --enable-debug

 Similar to verbose discussed in the previous section you can override
 this configuration setting by using

  $ make debug=0         -- no debug information 
  $ make debug=1         -- turn debugging on
 
 without the need to reconfigure. But be aware that --enable-debug is
 just  changing  flags given to your compiler. It will not change any
 names. For  example,  the name of ANTLR's core library is libantlr.a
 (using g++) regardless of whether debug is on or off.


 4. Examples
 ===========

 You may leave out the examples just by

  --disable-examples

 Note that you can't undo this  without reconfiguration. Nevertheless,
 we recommend to configure with examples, test them and to study them
 to get a full understanding  on  how  ANTLR works and - last but not
 least - about all it's capabilities.


 5. Bootstrap
 ============

 ANTLR's parser engine (ie. the parser that accepts a grammar file) is
 written in ANTLR  itself. From a logical point of view you would need
 ANTLR  to  build ANTLR. This chicken and egg problem is solved simply
 by having generated source files enclosed in the package.

 However, if you are doing some surgery  on ANTLR's internals you need
 to have a existing ANTLR version around.

 You can tell configure about this external ANTLR version by

   --with-antlr-jar=${some-install-dir}/lib/antlr.jar

 or by

   --with-antlr-cmd=${some-tool-running-antlr}


 The former version will  add  given  jar  file to the $CLASSPATH when 
 trying to compile grammar files ( *.g).

 Very similar you  can  also use --with-antlr-cmd to provide a program
 or  shell  script  to  compile grammar files. The name of the program
 does not matter but it needs to be exectuable and it  should  support
 all flags that can be given to ANTLR (check java antlr.Tools -h).  

 NOTE:

 Bootstraping  ANTLR  with  an  external jar file or program does will 
 only taken into account if there's  no lib/antlr.jar available in the
 build directory. In other words, if you bootstraped once and you make
 changes later on ANTLR's internals, then  the  previously  build  jar
 file antlr.jar will be used - regardless of your configuration 
 options. 


 6. Which Make?
 ==============

 You need a GNU make  to  run  the build. This is especially true when
 building  ANTLR  on Windows. Nevertheless, some efforts has been done
 to lower  the  dependency on GNU make for portability reasons. But we
 are not done yet.

 If  you  have  GNU make installed on your system but it's not in your
 PATH or you want to have a special version of make, you may tell this
 configure by either

   --with-make=${list-of-candidates}

 or by using environment variable $MAKE like

   MAKE=${list-of-candidates} ${srcdir}/configure

 Which  variant  you are using is a matter of your personal taste. But
 be aware that the command line argument is overriding the environment
 variable. Consider this example:

  MAKE=x-make ${srcdir}/configure --with-make="y-make z-make"
  
 Here configure will check your $PATH for y-make and z-make bug x-make
 is ignored.

 Note that the withespace seperated ${list-of-candidates} may also
 contain absolute path names. In that case $PATH is not consulted but
 the file is directly checked for existence. Here's an example:

  MAKE='make /usr/bin/make' ${srcdir}/configure

 Here your $PATH is consulted whether a "make" exsists. Then 
 /usr/bin/make is checked for existence.

 The first make found which is then a GNU make is the one choose to be
 used to build ANTLR.

 For consistency reasons you may also use --with-makeflags or variable
 $MAKEFLAGS to  pass specific flags to make. However, this information
 is not yet used. Right now the flags used are the flags provided when
 calling make.

 7. Which Java?
 ==============

 ANTLR  has  been tested with SUN Java 1.4.x using either SUN's javac
 Java compiler, IBM's jikes or GNU's gcj. Other systems have not been 
 tested and are not expected to work.

 The default search order is 

  jikes javac gcj

 It  is  therefore sufficient to have "jikes" in your $PATH to get it
 choosen by configure - regardless whether it precedes a javac or not
 in $PATH.

 You may change this default search by providing a list of candidates
 by either

   --with-javac=${candidate-list}

 or by

   JAVAC=${candidate-list}

 The candidates should be seperated by whitespace and may be relative
 or  absolute  path  names. Only in the former case a lookup in $PATH 
 takes place.

 By default options passed to a Java compiler are those who are 
 sufficient to compile ANTLR. You may pass other flags by either

   --with-javacflags=${flags}

   JAVACFLAGS=${flags}

 In most cases you want to leave the default flags intact but rather
 add your additional flags. To support this, ANTLR's build management
 interprets ${flags} like this:

    ${flags}        STANDARD FLAGS           RESULT
    --------------+-----------------+----------------------
    + f1 f2 .. fn |     F1 .. FN    |  F1 .. FN f1 f2 .. fn 
    - f1 f2 .. fn |     F1 .. FN    |  f1 f2 .. fn F1 .. FN
    = f1 f2 .. fn |     F1 .. FN    |  f1 f2 .. fn
    f1 f2 .... fn |     F1 .. F     |  f1 f2 .. fn
    --------------+-----------------+----------------------

 In other words, you can either tell configure to append (+), to
 prepend (-) or to substitute(=) your flags. 


 Note that this is also possible when running make. For example,

   $ make JAVAC=jikes JAVACFLAGS="+ -verbose"

 would use jikes to compile regardless of what has been configured
 before. Additionally the flag "-verbose" is used.


 So far we talked about compiling Java. Let's have now a look on how
 to execute class files. By default configure searches for

   java gij

 to run Java. As discussed before it is sufficient  to  have a Java in
 $PATH to get java selected. It has also to be noted that gij is still
 in experimental stage and not fully supported now.

 As before you may also provide additional flags to Java by using 
 either

  --with-javaflags=${flags} 

 or by using environment variable

   JAVAFLAGS=${flags}

 Again, ${flags} are getting interpreted according to table shown 
 above.

 8. Which C++ Compiler?
 ======================

 The algorithm  on  how  the C++ compiler is choosen and how to pass 
 additional flags are very much the same as discussed before for the
 Java compiler.

 The default candidate list for choosing a C++ compiler is

  bcc32 cl g++                      on Windows ; and
  aCC CC xlC xlC_r g++ cxx c++      on UNIX.

 To change this list use

  --with-cxx=${candidates}

 and use

  --with-cxxflags=${flags}

 to pass additional flags to the standard compiler flags. You can also 
 use $CXX and $CXXFLAGS if you like. This  will  then  also  work when 
 running make. 


 9. Which C# Compiler?
 =====================

 The only candidate for C# as time of writing is 

  csc

 for compiling C# source code. To change this option

  --with-csharpc=${candidates}

 and use

  --with-csharpcflags=${flags}

 for providing a list of additional options. Note that ${flags} are
 getting interpreted as discussed in the previous sections.

 Instead  of  command  line  arguments to configure you may also use
 $CSHARPC and $CSHARPCFLAGS.  This  variables  are also working when 
 running make.

 10. Which Python?
 =================

 Configure is  searching for "python" in your $PATH and in some well
 known locations. If  no "python" can be found, language support for
 Python is disabled.

 You may use

  --with-python="${candidates}"

 to provide a list of Python candidates and further you may use

  --with-pythonflags="${flags}"

 to  provide  a  list of (additional) flags to be passed to Python on
 execution. Note that ${flags} is getting interpreted as discussed in
 the previous sections.

 You may also use $PYTHON and $PYTHONFLAGS instead. This variables are
 then also working when running make. Note  that  those  variable  may
 override what has been configured before without any warning.



______________________________________________________________________
FURTHER DETAILS ON ANTLR'S BUILD SETUP?


In allmost all cases it is assumed to be sufficient to change compiler
settings by using either --with-${lang}flags or by using ${LANG}FLAGS.

It's most likely not sufficient if you want to support a new compiler,
tool or a new operating system.

The general idea is  to  have a configured shell script for each tool 
or compiler being used rather than doing the scripting within the
Makefile itself. The reason for this is that scripting in Makefiles is
rather hard  to read and a pain to debug (for example, there's no line
information).

The configured shell scripts are to be found in subdirectory "scripts"
within the build directory. Their originals are located in 

 ${srcdir}/scripts

This scripts are known at time of writing:

 antlr.sh.in  -  runs "java antlr.Tools"
 cxx.sh.in    -  run C++ compiler
 cpp.sh.in    -  run C/C++ preprocessor (for dependencies).
 jars.sh.in   -  how to make a static library (aka jar file)(Java)
 javac.sh.in  -  run Java compiler (also when using jikes etc)
 lib.sh.in    -  how to make a static library (C++)
 link.sh.in   -  how to make a executable (C++)
 python.sh.in -  how to run python

A Makefile contains nothing more than variables and rules and in all-
most all cases (but simple exceptions)  the command behind a rule is
just executing a script.

Note that these scripts are not intended to be used  to  compile C++, 
Java etc in general. Instead this scripts are specialized for ANTLR.

For example, the script "lib.sh" has  a  very simple interface. All 
you can provide  is  a list  of object files. There is no option to
tell about the library  name  to be build. Instead the library name
is set by configure and available by using @ANTLR_LIB@ in all
configured files.

Unfortunatly, all scripts are rather complex and limiting ourselfs of
not using  shell  functions  (portability)  is not going make changes
easier.

In  general  you  should  only edit the upper part of any script till 
there's a line like "**NO  CHANGE NECESSARY BELOW THIS LINE - EXPERTS
ONLY**".


Then let's have now a closer look at cxx.sh.in. The other scripts are
very similar. I'm going to discuss here only the relevant parts - this
is open source  after  all any you may try to understand it by reading
the source code :-)

 ARGV="$*"

In general all arguments given to the script file are collected with-
in variable $ARGV. In some scripts, the very first  argument  has  a 
special meaning - usually it tells about the target to be created. In
such a case 

 TARGET

would hold the first argument given and ARGV would hold all others.

 if test -z "${CXX}" ; then
  CXX="@CXX@"
  cxx="@cxx@"
 else
  cxx="`basename $CXX`"
  cxx="`echo $cxx|sed 's,\..*$,,'`"
 fi

This script snippet checks about the compiler to be used for compiling
C++ source. Note that we have two variables,  CXX  and cxx. The former
holds usually the absolute path of  the  compiler  as  configured. The
later, cxx, contains the  logical  compiler name. The logical compiler
name is "gcc" for GNU, "cl" for Microsoft C++ etc. etc.

The logical compiler name is usually configured and available as @cxx@.
However,  a user  overrides  the  configuration  by  using environment 
variable CXX, the  logical  compiler  name is computed by removing any
extension.

In a further section (similar in other scripts) we set specific flags
depending on the  l o g i c a l  compiler name.  As you can see it is
rather important to the logical name proper.

case "${cxx}" in
  gcc)
    cxxflags="-felide-constructors -pipe"
    case "${DEBUG}" in
      0)
        cxxflags="-O2 -DNDEBUG ${cxxflags}"
        ;;
      1)
        cxxflags="-g ${cxxflags} -W -Wall"
        ;;
    esac
    ;;
  cl)
    cxxflags="/nologo -GX -GR" 
  [[skipped]]
esac

In the snippet shown you can see the handling of "gcc" and "cl". Note that
the compiler flags are saved in $cxxflags and not in $CXXFLAGS. Reason
for this is that handling  of environment variable $CXXFLAGS is rather
longish due to ANTLR's  special interpretation mechanism (as discussed 
in an earlier section).

In some cases flags may depend on platform in use. In that case you may
do something like:


  case ${cxx} in
   gcc)
        case @build_os@ in
         cygwin)
             ## cygwin specific flags ..
             ;;
          sparc)
             ## sparc specific ..
             ;;
          *)
             ## all others
             ;;
        esac
   ..
  esac

Of course you can utilize here the full scripting power to set flags
required to get compilation job done.

______________________________________________________________________
FAQ?

 1. How to setup jikes boot classpath?
 =====================================

 Jikes (http://www-124.ibm.com/developerworks/oss/jikes) is just a
 Java compiler that needs to know  about  Java's core classes, ie.
 rt.jar, for a successful build of ANTLR. By default configure tries
 to locate rt.jar by searching $PATH for a java executable and 
 relative to where found, for ../jre/lib/rt.jar.

 If this search fails or if you want to pass a different Java core or
 further core libraries, you may use either option 

   --with-bootclasspath="${args}"

 or environment variable

   BOOTCLASSPATH="${args}"

 The list of arguments, ${args}, is supposed to be list of whitespace
 seperated files or directories. Configure  will  validate  that each
 argument exists and will fail  otherwise.  Besides this there are no
 further validations  done  -  you  are supposed to know what you are
 doing. Note also that  configure will not perform any search in case
 a bootclasspath is given.

 The arguments given are concatenated using platform specific argument
 seperator (ie. ";" or ":") and passed to option --bootclasspath.

 2. Can I just say "make" after having unpacked ANTLR?
 =====================================================
 
 No - as explained previously you need to run "configure" before you
 can issue a "make".

 3. How do I cleanup afterwards?
 ===============================

 You do a "make clean" to remove all object files. If  you do a "make
 distclean", then all files generated by ANTLR are  also  removed. In
 this case you need a external antlr.jar somewhere to rebuild.

 If you are using a external build directory you may just remove the
 whole directory without any harm.

 4. Is it safe to edit a Makefile?
 =================================

 In general do not edit  files  named  Makefile.  Instead edit files
 named Makefile.in. Configure or config.status will override changes
 you made in a Makefile on any run.

 5. I changed Makefile.in - what's next?
 =======================================

 Just run make again. Each Makefile contains a rule that automatically
 remakes itself if corresponding Makefile.in has changed.

 This automatic rule works fine in general.  However,  if  you change 
 Makefile/Makefile.in in such a way that make rejects it's  execution
 then you need to remake Makefile yourself.

 This can be done by

   $ cd ${builddir}
   $ ./config.status ${your-makefile}

 Here's an example. Assume that "antlr/Makefile" is corrupted. The do
 this:

   ./config.status antlr/Makefile 

 You can also issue just a 

   $ ./config.status

 In this case all configured files are regenerated.

 6. My configure has changed - what's next?
 =============================================

 You need to reconfigure each build directory to get the changes. So
 far no automatic rule has been implemented. The easiest way of being
 up-to-date is:

  $ cd ${builddir} && ./config.status --recheck && make

 7. Where do I find antlr.jar?
 =============================
 
 Have a look at "lib".  Should  be there - but it is subject of having
 enabled  Java  or not.  Note that Java gets automatically disabled if 
 there's no  sufficient  Java compiler found (warning message would be
 dumped in that case).

 8. How can I make "make" nosiy?
 ===============================

 By default make just tells you what's going on in a very brief way. 
 To change this just do this:

  $ make verbose=1

 You can also tell configure to turn verbosity on by default by using
 option

  --enable-verbose.

 Run "configure --help" for a list of options available.

 9. Am I able to run "make" in a subdirectory?
 =============================================

 Sure.

 10. Is it safe to remove configured subdirectory?
 =================================================

 In general "yes" but you want to do this only within the build tree.

 For example, let's assume that you are tired of getting standard
 examples tested. Then just move on and remove subdirectory
 "examples".


______________________________________________________________________
LIST OF CONFIGURED VARIABLES?

 ANTLRFLAGS
 ANTLR_ACTION_FILES
 ANTLR_ANTLR_FILES
 ANTLR_COMPILE_CMD
 ANTLR_CYGWIN
 ANTLR_JAR
 ANTLR_LIB
 ANTLR_MINGW
 ANTLR_NET
 ANTLR_PY
 ANTLR_TOKDEF_FILES
 ANTLR_WIN32
 ANTLR_WITH_ANTLR_CMD
 ANTLR_WITH_ANTLR_JAR
 AR
 ARFLAGS
 AS
 BOOTCLASSPATH
 CSHARPC
 CSHARPCFLAGS
 CSHARP_COMPILE_CMD
 CXX_COMPILE_CMD
 CXX_LIB_CMD
 CXX_LINK_CMD
 CYGPATH
 DEBUG
 EXEEXT
 JAR
 JARFLAGS
 JAR_CMD
 JAVA
 JAVAC
 JAVACFLAGS
 JAVAFLAGS
 JAVA_CMD
 JAVA_COMPILE_CMD
 LIBEXT
 MAKE
 OBJEXT])
 PATCHLEVEL
 PYTHON
 PYTHONFLAGS
 SUBVERSION
 VERBOSE
 VERSION
 WITH_EXAMPLES
 abs_this_builddir
 cxx
 jar
 java
 javac

______________________________________________________________________
PLATFORMS?

 ANTLR  has  been  developed  and  tested on platforms listed below. A 
 platform is considered supported and tested if basically all standard
 examples are working.

 Devel for ANTLR 2.7.5 took place on:

 i686-linux2.6.3-7mk  
   - Java 1.4.2, gcj 3.3.4, jikes 1.16, 1.17, 1.18, 1.19, 1.20, 1.21, 1.22
   - gcc 3.3.2, gcc 3.3.4
   - Python 2.3, 2.4 
   - DotGNU 0.6.0

 i686-cygwin_nt-5.1
   - Java 1.4.2, gcj 3.3.3, jikes 1.22
   - gcc 3.3.3, bcc32 5.6 (Borland C++), cl 13.10.3077 (Microsoft C++)
   - csc 7.10.6001.4 (Visual C# .NET Compiler)
   - Python 2.2, 2.3, 2.4
   - Mono 1.0.5

 ANTLR has been tested on:

 MinGW-3.1.0.1 (needs manual install of cygpath!)
  - MSys 1.0.10
  - Java 1.5.0-b64
  - gcc 3.4.1
 
 PowerPC or RS/6000:
  * powerpc-apple-darwin6.8 (MacOS 1o, "Jaguar")
    - Java 1.4.1, jikes 1.15
    - gcc 3.1
    - Python 2.2
    - Mono (?) also reported to work.   

 SPARC:
  * sparc-sun-solaris2.8
    - Java 1.4.1
    - SUN CC 5.6

 Known  n o t  to work:
 - jikes 1.13 and older due to missing classpath and bootclasspath
   options. Jikes 1.14 and 1.15 are not tested due to compilation
   problems compiling jikes itself (on Mandrake 1o).

 - Python < 2.2 will not work.

 - gcc 2.* will not work.

 - You need to have GNU make (for building).
======================================================================
             INSTALL.txt - last update January 11th, 2005