[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DJGPP specific patch for bison
From: |
Juan Manuel Guerrero |
Subject: |
Re: DJGPP specific patch for bison |
Date: |
Fri, 31 Aug 2001 14:15:33 +0200 |
DJGPP support for bison, patch 2/2
diff -acprNC5 bison-1_29-branch.orig/djgpp/README.in
bison-1_29-branch.djgpp/djgpp/README.in
*** bison-1_29-branch.orig/djgpp/README.in Thu Jan 1 00:00:00 1970
--- bison-1_29-branch.djgpp/djgpp/README.in Thu Aug 30 09:14:30 2001
***************
*** 0 ****
--- 1,309 ----
+ This is a port of GNU Bison @VER@ to MSDOS/DJGPP.
+
+
+ 1.: DJGPP specific changes.
+ =======================
+
+ There are no DJGPP specific changes. Starting with Bison 1.29,
+ the sources can be compiled out-of-the-box using the DJGPP tools.
+ 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 in Win9X), then the
+ standard posix file names 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 address@hidden@b.zip or
+ djtarx address@hidden@b.zip or
+ pkunzip -d address@hidden@b.zip
+
+ 2.3.: It must be noticed that starting with Bison 1.29, the parser files
+ bison.simple and bison.hairy are installed into %DJDIR%/share/bison.
+ This is different from previous versions and ports of Bison. Due to
+ this, you must delete the following lines:
+
+ [bison]
+ BISON_HAIRY=%DJDIR%/lib/bison.hai
+ BISON_SIMPLE=%DJDIR%/lib/bison.sim
+
+ from your djgpp.env. These lines set the BISON_SIMPLE and BISON_HAIRY
+ environment variables to point to obsolete parser files. This must be
+ avoided by deleting those entries from the djgpp.env file.
+
+ 2.4.: 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.5.: 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.6.: 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 address@hidden@s.zip or
+ djtarx address@hidden@s.zip or
+ pkunzip -d address@hidden@s.zip
+
+ Source distributions downloaded from one of the GNU FTP sites can be
+ unziped by running the following command:
+
+ djtar -x @address@hidden
+
+ (The name of the distribution archive and the top-level directory will
+ be different for versions other than @address@hidden)
+
+ 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 (address@hidden@)
+ 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:address@hidden@\djgpp\config x:/src/gnu/address@hidden@ 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:address@hidden@\djgpp\config x:/src/gnu/address@hidden@ 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 <address@hidden>.
+ Send suggestions and bug reports concerning the DJGPP port to
+ comp.os.msdos.djgpp or <address@hidden>.
+
+
+ Enjoy.
+
+ Guerrero, Juan Manuel <address@hidden>
diff -acprNC5 bison-1_29-branch.orig/doc/bison.texinfo
bison-1_29-branch.djgpp/doc/bison.texinfo
*** bison-1_29-branch.orig/doc/bison.texinfo Thu Aug 16 20:29:46 2001
--- bison-1_29-branch.djgpp/doc/bison.texinfo Thu Aug 30 18:34:32 2001
*************** will produce @file{output.c++} and @file
*** 4778,4787 ****
--- 4778,4789 ----
@menu
* Bison Options:: All the options described in detail,
in alphabetical order by short options.
* Environment Variables:: Variables which affect Bison execution.
* Option Cross Key:: Alphabetical list of long options.
+ * Extension Limitations Under DOS:: Bison output files extension differences
+ depending on the DOS/Windows file
system flavour used.
* VMS Invocation:: Bison command syntax on VMS.
@end menu
@node Bison Options, Environment Variables, , Invocation
@section Bison Options
*************** a file called @file{bison.hairy} instead
*** 4930,4940 ****
also be specified or overridden in a similar fashion, with the
@code{BISON_HAIRY} environment variable.
@end table
! @node Option Cross Key, VMS Invocation, Environment Variables, Invocation
@section Option Cross Key
Here is a list of options, alphabetized by long option, to help you find
the corresponding short option.
--- 4932,4942 ----
also be specified or overridden in a similar fashion, with the
@code{BISON_HAIRY} environment variable.
@end table
! @node Option Cross Key, Extension Limitations Under DOS, Environment
Variables, Invocation
@section Option Cross Key
Here is a list of options, alphabetized by long option, to help you find
the corresponding short option.
*************** the corresponding short option.
*** 4974,4984 ****
--verbose -v
--version -V
@end example
@end ifinfo
! @node VMS Invocation, , Option Cross Key, Invocation
@section Invoking Bison under VMS
@cindex invoking Bison under VMS
@cindex VMS
The command line syntax for Bison on VMS is a variant of the usual
--- 4976,5016 ----
--verbose -v
--version -V
@end example
@end ifinfo
! @node Extension Limitations Under DOS, VMS Invocation, Option Cross Key,
Invocation
! @section Extension Limitations under DOS
! @cindex extension limitations under DOS
! @cindex DOS
!
! On DOS/Windows 9X systems, the file name extensions, like @file{.tab.c},
! that may be used depend on the file system used. The plain DOS file system
! has limited file name length and does not allow more than a single dot
! in the file name.
!
! The DJGPP port of @code{bison} will detect at runtime if (LFN) long file name
! support is available or not. LFN support will be available in a DOS session
! under Windows 9X and successors. If LFN support is available the DJGPP port
! of @code{bison} will use the standard POSIX file name extensions. If LFN
! support is not available, then the DJGPP port of @code{bison} will use
! DOS specific file name extensions.
!
! @noindent This table summarizes the used extensions:
!
! @multitable @columnfractions 0.1 0.45 0.45
! @item @tab LFN extension (Win9X) @tab SFN extension (plain DOS)
! @item @tab @file{.tab.c} @tab @file{_tab.c}
! @item @tab @file{.tab.h} @tab @file{_tab.h}
! @item @tab @file{.tab.cpp} @tab @file{_tab.cpp}
! @item @tab @file{.tab.hpp} @tab @file{_tab.hpp}
! @item @tab @file{.output} @tab @file{.out}
! @item @tab @file{.stype.h} @tab @file{.sth}
! @item @tab @file{.guard.c} @tab @file{.guc}
! @end multitable
!
! @node VMS Invocation, , Extension Limitations Under DOS, Invocation
@section Invoking Bison under VMS
@cindex invoking Bison under VMS
@cindex VMS
The command line syntax for Bison on VMS is a variant of the usual
diff -acprNC5 bison-1_29-branch.orig/Makefile.am
bison-1_29-branch.djgpp/Makefile.am
*** bison-1_29-branch.orig/Makefile.am Mon Aug 27 12:14:06 2001
--- bison-1_29-branch.djgpp/Makefile.am Wed Aug 29 16:43:36 2001
***************
*** 1,13 ****
## Process this file with automake to produce Makefile.in -*-Makefile-*-
AUTOMAKE_OPTIONS = 1.5 check-news readme-alpha
ACLOCAL_AMFLAGS = -I m4
! SUBDIRS = config intl po lib src doc m4 tests
! EXTRA_DIST = REFERENCES configure.bat OChangeLog Makefile.maint GNUmakefile
DISTCLEANFILES = intl/libintl.h
## ---------------------------- ##
--- 1,13 ----
## Process this file with automake to produce Makefile.in -*-Makefile-*-
AUTOMAKE_OPTIONS = 1.5 check-news readme-alpha
ACLOCAL_AMFLAGS = -I m4
! SUBDIRS = config intl po lib src doc m4 tests djgpp
! EXTRA_DIST = REFERENCES OChangeLog Makefile.maint GNUmakefile
DISTCLEANFILES = intl/libintl.h
## ---------------------------- ##
diff -acprNC5 bison-1_29-branch.orig/src/files.c
bison-1_29-branch.djgpp/src/files.c
*** bison-1_29-branch.orig/src/files.c Wed Aug 15 10:53:16 2001
--- bison-1_29-branch.djgpp/src/files.c Fri Aug 31 00:55:52 2001
*************** compute_base_names (void)
*** 305,317 ****
The precise -o name will be used for FTABLE. For other output
files, remove the ".c" or ".tab.c" suffix. */
if (spec_outfile)
{
! #ifdef MSDOS
strlwr (spec_outfile);
! #endif /* MSDOS */
/* BASE_LENGTH includes ".tab" but not ".c". */
base_length = strlen (spec_outfile);
ext_index = get_extension_index (spec_outfile);
/* If the initial segment of extension contains 'c' or a 'C', I assume
--- 305,317 ----
The precise -o name will be used for FTABLE. For other output
files, remove the ".c" or ".tab.c" suffix. */
if (spec_outfile)
{
! #ifdef NO_CASE_PRESERVE
strlwr (spec_outfile);
! #endif /* NO_CASE_PRESERVE */
/* BASE_LENGTH includes ".tab" but not ".c". */
base_length = strlen (spec_outfile);
ext_index = get_extension_index (spec_outfile);
/* If the initial segment of extension contains 'c' or a 'C', I assume
*************** compute_base_names (void)
*** 339,351 ****
are `foo'.
Construct names from it. */
if (spec_file_prefix)
{
! #ifdef MSDOS
strlwr (spec_file_prefix);
! #endif /* MSDOS */
short_base_name = xstrdup (spec_file_prefix);
base_name = XMALLOC (char,
strlen (short_base_name) + strlen (EXT_TAB) + 1);
stpcpy (stpcpy (base_name, short_base_name), EXT_TAB);
--- 339,351 ----
are `foo'.
Construct names from it. */
if (spec_file_prefix)
{
! #ifdef NO_CASE_PRESERVE
strlwr (spec_file_prefix);
! #endif /* NO_CASE_PRESERVE */
short_base_name = xstrdup (spec_file_prefix);
base_name = XMALLOC (char,
strlen (short_base_name) + strlen (EXT_TAB) + 1);
stpcpy (stpcpy (base_name, short_base_name), EXT_TAB);
*************** output_files (void)
*** 433,445 ****
src_extension = ".c";
if (!header_extension)
header_extension = ".h";
attrsfile = stringappend (short_base_name, EXT_STYPE_H);
! #ifndef MSDOS
! stringappend (attrsfile, header_extension);
! #endif /* MSDOS */
/* Output the main file. */
if (spec_outfile)
obstack_save (&table_obstack, spec_outfile);
else
--- 433,443 ----
src_extension = ".c";
if (!header_extension)
header_extension = ".h";
attrsfile = stringappend (short_base_name, EXT_STYPE_H);
! stringappend (attrsfile, EXT_TYPE (header_extension));
/* Output the main file. */
if (spec_outfile)
obstack_save (&table_obstack, spec_outfile);
else
*************** output_files (void)
*** 459,471 ****
{
char *temp_name;
obstack_save (&attrs_obstack, attrsfile);
temp_name = stringappend (short_base_name, EXT_GUARD_C);
! #ifndef MSDOS
! temp_name = stringappend (temp_name, src_extension);
! #endif /* MSDOS */
obstack_save (&guard_obstack, temp_name);
}
if (verbose_flag)
/* We used to use just .out if spec_name_prefix (-p) was used, but
--- 457,467 ----
{
char *temp_name;
obstack_save (&attrs_obstack, attrsfile);
temp_name = stringappend (short_base_name, EXT_GUARD_C);
! temp_name = stringappend (temp_name, EXT_TYPE (src_extension));
obstack_save (&guard_obstack, temp_name);
}
if (verbose_flag)
/* We used to use just .out if spec_name_prefix (-p) was used, but
diff -acprNC5 bison-1_29-branch.orig/tests/Makefile.am
bison-1_29-branch.djgpp/tests/Makefile.am
*** bison-1_29-branch.orig/tests/Makefile.am Fri Aug 3 12:13:42 2001
--- bison-1_29-branch.djgpp/tests/Makefile.am Tue Aug 28 22:39:02 2001
*************** check-local: atconfig $(srcdir)/testsuit
*** 29,40 ****
$(SHELL) $(srcdir)/testsuite
testsuite: atgeneral.m4 suite.at $(SUITE)
$(M4) -I $(srcdir) atgeneral.m4 suite.at | \
sed -e 's/[ ]*$$//' | \
! sed -e '/^$$/N;/\n$$/D' > address@hidden
! chmod +x address@hidden
! mv address@hidden $@
CLEANFILES = debug-*.sh empty
DISTCLEANFILES = atconfig
MAINTAINERCLEANFILES = testsuite
--- 29,40 ----
$(SHELL) $(srcdir)/testsuite
testsuite: atgeneral.m4 suite.at $(SUITE)
$(M4) -I $(srcdir) atgeneral.m4 suite.at | \
sed -e 's/[ ]*$$//' | \
! sed -e '/^$$/N;/\n$$/D' > t-$@
! chmod +x t-$@
! mv t-$@ $@
CLEANFILES = debug-*.sh empty
DISTCLEANFILES = atconfig
MAINTAINERCLEANFILES = testsuite