This is a port of GNU Bison 1.29 to MSDOS/DJGPP.


1.:     DJGPP specific changes.
        =======================

        The DJGPP port of Bison offers LFN and SFN support depending on which
        OS it is running. If LFN support is available or not is determinated at
        run time. If LFN support is available (DOS session under Win9X), the
        standard posix file name extensions will be used. These are: y.tab.c,
        y.tab.c++, y.tab.h, y.output, etc. If only SFN support is available
        (plain DOS), then the standard MSDOS short file names will be used.
        These are: y_tab.c, y_tab.h, y.out, etc.


2.:     Installing the binary package.
        ==============================

2.1.:   If you have downloaded a precompiled binary distribution from some
        Simtel.NET mirror, copy the binary distribution into the top DJGPP
        installation directory. If you are installing Bison on a dual DOS/
        WINDOWS 9X system, you *MUST* first turn off the generation of numeric
        tails for the 8.3 aliases Windows creats for long file names.
        For information about how to do this, please read the DJGPP FAQ List
        V 2.30, chapter 22.19: "How to Set Up a Dual DOS/Windows Installation".
        It must be noticed that bison.exe does not contain any code to handle
        8.3 aliases with numeric tails. This implies that if you install the
        binary distribution in a DOS session of Win9X (LFN) **WITHOUT** turning
        off the numeric tail generation you will **NOT** be able to use Bison
        on plain DOS. The reason for this is that aliases like BISON~1.SIM and
        BISON~1.HAI will be created for the parser files bison.simple and
        bison.hairy instead of the appropiate ones BISON.SIM and BISON.HAI.
        After having installed the package, you can turn on numerical tail
        generation again if you wish. If this is not done, Bison will not be
        able to find its parser files when you switch to plain DOS.

2.2.:   Copy the binary distribution into the top DJGPP installation directory,
        just unzip it preserving the directory structure running *ONE* of the
        following commands:
          unzip32 bsn129b.zip      or
          djtarx bsn129b.zip       or
          pkunzip -d bsn129b.zip

2.3.:   This port offers NLS, this means that you can expect the program to
        talk your mother tongue if supported. To activate this native language
        support (NLS) some new entries must be added to the global part of your
        djgpp.env file which is located in the top DJGPP installation directory.
        The global part of your djgpp.env is everything *BEFORE* the *FIRST*
        line that looks like:
[xxxx]
        where xxxx stands for the name of some DJGPP binary.
        Add the following line to the first part of your djgpp.env:

+LANG=xx
+LANGUAGE=yy:zz

        The line must be completely shifted to the left in your djgpp.env file.
        Please note the plus sign at the beginning of the line. This plus sign
        should **NOT** be omited or a lot of shell scripts, in this and in
        other packages, that try to reset this value will stop working. The
        LANG entry is obligatory, the LANGUAGE entry may be omited. The
        LANGUAGE variable allows you to select an alternate catalog than the
        one stipulated by LANG. Replace xx, yy and zz by the language code of
        the catalogs you want to use. It should be noticed that LANGUAGE has
        *ALWAYS* higher priority than LANG. The LANG variable not only selects
        a catalog, it also specifies the dos codepage that will be used as
        locale charset. All this means that the translation strings contained
        in the catalogs (.mo files) will be recoded at runtime to the dos
        codepage stipulated by the value of LANG. This runtime recoding is
        needed because the .mo files may have been written using a charset
        that is not compatible with the charset that will be used on the
        machine and OS where the .mo files contents will be displayed.
        The .po files of the GNU packages, from which the .mo files are
        generated, are typical examples of this. They have been written
        using some ISO-8859-nn charset (an unix charset) and shall be
        displayed on a DOS/WIN95 machine that uses some dos codepage.

        Some examples:
        If you only want to use the catalog containing the translations for
        your mother tongue (in my case the spanish translations) the above
        lines will only use the LANG variable and will look like this:

+LANG=es

        In this case, LANG defines the translation to be used and at the same
        time the locale charset (CP850 in this case) to be used for the on-the-fly
        recoding of the catalog (.mo file) contents.
        If you want to use the spanish (es) and german (de) catalogs the above
        lines will look like this:

+LANG=es
+LANGUAGE=es:de

        In this case a DJGPP binary that has been compiled with NLS support
        will first search for the spanish translation of a string. If a
        translation for that particular string can not be found in the spanish
        .mo file then it will search for a german translation of that string in
        the german .mo file and if a german translation of that string can also
        not been found it will default to display the build-in english string.
        No mather if a spanish, a german or an english build-in string is
        selected, the string is always recoded to the dos codepage stipulated
        by LANG. In this case: CP850.
        If you want to reverse this search order the above lines would look
        like this one:

+LANG=es
+LANGUAGE=de:es

        Now let us assume that an user wants to use the swedish catalogs on
        a machine that loads codepage CP437 when it is booted. It should be
        noticed that the locale charset for Sweden is CP850 and not CP437.
        In this case, the lines must look like this:

+LANG=en_US
+LANGUAGE=sv

        LANG reflects the available codepage/charset and LANGUAGE selects the
        wanted translation catalog. en_US means CP437. Now, the contents of the
        catalog are recoded to CP437 instead to CP850 because CP437 is the
        codepage used to display messages on screen. Of course, not every
        combination of catalogs and locale charset (dos codepages) makes sense.
        E.G.: selecting as locale charset chinese (LANG=zh_TW) and the french
        translations (LANGUAGE=fr) will certainly not generate an usefull
        screen output.

        The content of LANG is a language code. Examples are fr for french,
        en_US for US english, etc. This language code is an alias for the
        locale charset to be used for runtime recoding. The complete list of
        all available aliases can be found in %DJDIR%/lib/charset.alias. This
        file is a table with two entries: left entry is the alias (en_US,
        de_AT, etc.), right entry is the corresponding dos codepage that will
        be used for that language code (alias). It should be noticed that it is
        also possible to select a codepage directely. E.G.: Instead of setting:

+LANG=en_US

        you may directely set:

+LANG=CP437

        This overwrites any settings in charset.alias.
        Please note that if you omit the LANG environment variable,
        the LANGUAGE variable will not be honored at all. Because the
        information about what locale charset shall be used is needed,
        if LANG is omitted by the user LANGUAGE will be ignored and no
        translation will be done at all.
        If for some reason you want to disable NLS, then you should comment
        out the LANG variable or select 'C' as your catalog:

+LANG=C

        Users not familiar with djgpp.env should refer to kb.info.
        This document can be read running the command:
          info -f kb -n DJGPP.ENV

2.4.:   To create an entry for the bison info docs in your dir file
        run from the top DJGPP installation directory the command:
          install-info --info-dir=./info ./info/bison.info

2.5.:   The binary distributed in this package have NLS support.
        E.G. run the command:
          bison
        and the binary should talk to you in your mother tonge, if
        supported.
        For futher information about GNU bison please read the info docs.


3.:     Building the binaries from sources.
        ===================================

3.1.:   To build the binaries you will need the following binary packages:
          djdev203.zip (or a later but NOT a prior version)
          bsh203b.zip  (or a later but NOT a prior version)
          gcc2953b.zip, bnu2112b.zip, mak3791b.zip,
          fil40b.zip, shl112b.zip, txt20b.zip,
          txi40b.zip, grep24b.zip, sed302b.zip,
          m4-14b.zip, gtxt039b.zip and licv17b.zip

        If you want to run the check you will need also:
          dif272b.zip

        All this packages can be found in the v2gnu directory of any
        Simtel.NET mirror.
        If you want NLS you must have gtxt039b.zip and licv17b.zip or later
        versions installed before configuring or compiling the package or the
        configuration and build process will fail.
        You will need bsh203b.zip or later and *NOT* a prior version or the
        build will fail. The same applies to djdev203.zip. You *MUST* use the
        updated version of shl112b.zip (date: 2000-08-11).
        This updated versions have been recompiled with djdev203.zip and know
        about the "/dev/env" functionality introduced with djdev203.zip. All the
        other packages are the ones I have used to build the binaries from this
        sources. Previuos versions of this packages may do the job as well but
        I have not tested this.

3.2.:   Create a temporary directory and copy the source package into the
        directory. If you download the source distribution from one of the
        DJGPP archives, just unzip it preserving the directory structure
        running *ONE* of the following commands:
          unzip32 bsn129s.zip      or
          djtarx bsn129s.zip       or
          pkunzip -d bsn129s.zip

3.3.:   The DJGPP package is preconfigured for NLS support and for run time
        recoding using the functionality provided by libiconv.a. This implies
        that gtxt039b.zip licv17b.zip or later versions of these both packages
        *MUST* be installed *before* you try to compile the package or the
        build process will fail.
        If you compile this package with a later version of libc.a or if you
        prefer no NLS support at all you will have to reconfigure this package.
        The configuration batch file of this package, located in the djgpp
        directory, allows you to enable or disable NLS support, enable or
        disable the dependency tracking system and to compile from a different
        partition than from where the sources are located. config.bat always
        configures the package for NLS support enabled, dependency tracking
        system disabled and for in-place compilation if no options are given.
        The available NLS options are:
          NLS
          no-NLS
        and the dependency tracking options are:
          dep
          no-dep

        If for some reason you want some other package configuration than the
        default one you will have to reconfigure the package. For this purpose
        cd into the top srcdir (bison-1.29)
        and run the following command:
          djgpp\config no-NLS dep

        You **MUST** specify "no-NLS" and "dep" or config.bat will default to
        "NLS" and "no-dep".
        To build the programs in a directory other than where the sources are,
        you must add a parameter that specifies the source directory,
        e.g:
          x:\src\gnu\bison-1.29\djgpp\config x:/src/gnu/bison-1.29 no-NLS

        Lets assume you want to build the binaries in a directory placed on a 
        different drive (z:\build in this case) from where the sources are,
        then you will run the following commands:
          z:
          cd \build
          x:\src\gnu\bison-1.29\djgpp\config x:/src/gnu/bison-1.29 no-NLS

        If you want NLS support you will omit "no-NLS" or replace it by
        "NLS" in the above examples. The order of the different options
        do *NOT* matter. You *MUST* use forward slashes to specify the
        source directory.

        This batch file will set same environment variables, make MSDOS
        specific modifications to the Makefile.ins and supply all other
        needed options to the configure script.

3.4.:   To compile the package run from the top srcdir the command:
          make

3.5.:   Now you can run the tests if you like.
        From the top srcdir run the command:
          make check

        Non test should fail.

3.6.:   To install the binaries, header, library, catalogs, and info docs
        run the following command from the top srcdir:
          make install CATALOGS="xx.gmo yy.gmo zz.gmo"
        or
          make install CATALOGS="xx.gmo yy.gmo zz.gmo" prefix=z:/some/other/place

        This will install the products into your DJGPP installation tree given
        by the default prefix "/dev/env/DJDIR". If you prefer to install them
        into some other directory you will have to set prefix to the appropiate
        value. Replace xx, yy and zz by the language codes of the catalogs you
        want to install.

3.7.:   Now you have to set the LANG environment variable.
        Please refer to section 2.3 for further information.



        Send GNU bison specific bug reports to <bug-bison@gnu.org>.
        Send suggestions and bug reports concerning the DJGPP port to
        comp.os.msdos.djgpp or <djgpp@delorie.com>.


Enjoy.

        Guerrero, Juan Manuel <st001906@hrz1.hrz.tu-darmstadt.de>
