From: Bruno Haible MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15026.24986.297621.484205@honolulu.ilog.fr> Date: Fri, 16 Mar 2001 19:55:22 +0100 (CET) To: "Juan Manuel Guerrero" Cc: Eli Zaretskii , djgpp-workers AT delorie DOT com Subject: Re: gettext pretest available In-Reply-To: <465C8DC1374@HRZ1.hrz.tu-darmstadt.de> References: <439E9106868 AT HRZ1 DOT hrz DOT tu-darmstadt DOT de> <465C8DC1374 AT HRZ1 DOT hrz DOT tu-darmstadt DOT de> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > I have tried to compile gettext-20010309.tgz out of the box > and I have found the following difficulties: Thanks for the repeated testing. > 1) ./m4/gettext.m4 > This file *still* contains the following line: > [case " $CONFIG_FILES " in *" po/Makefile.in "*) > makeing it completely impossible to give an alternative for po/Makefile.in. > But MSDOS/DJGPP needs the alternative: po/Makefile:po/Makefile.in-in. Thanks for reminding me. I've changed it to case " $CONFIG_FILES " in *" po/Makefile.in "* | *" po/Makefile.in:"*) > 2) ./po/Makefile.in.in > If a previous version of msgfmt.exe is **not** installed then the compilation > will fail with the following error message: po/da.gmo should normally be newer than po/da.po. This was broken in the gettext-2001-03-09 snapshot. This should be fixed in the release. > It can be clearly seen that: > PATH=../src:$$PATH > has been omited. This omission breaks the compilation process because > the programs are searched along the path but not in the src/ subdirectory. > If the programs can *not* be found along the patch then the compilation > must fail. It is completelly unclear to me why this has been changed at all. The ChangeLog entry says it: * Makefile.in.in (GMSGFMT, XGETTEXT): Remove useless PATH setting. The macros @GMSGFMT@ and @XGETTEXT@ expand to absolute pathnames. > 3) ./tests/Makefile.am > The testsuit dies with the following error message: > Making check in tests > make.exe[1]: Entering directory `z:/_/gettext-/tests' > gcc -g -O2 tstgettext.c -o tstgettext > In file included from tstgettext.c:3: > ../src/gettext.c:23: getopt.h: No such file or directory (ENOENT) > In file included from tstgettext.c:3: > ../src/gettext.c:28: error.h: No such file or directory (ENOENT) > ../src/gettext.c:29: system.h: No such file or directory (ENOENT) > ../src/gettext.c:37: libgnuintl.h: No such file or directory (ENOENT) > make.exe[1]: *** [tstgettext] Error 1 > make.exe[1]: *** No rule to make target `cake', needed by `all-local'. > make.exe[1]: Target `check' not remade because of errors. > make.exe[1]: Leaving directory `z:/_/gettext-/tests' > make.exe[1]: Entering directory `z:/_/gettext-' > make.exe[1]: Leaving directory `z:/_/gettext-' > make.exe: *** [check-recursive] Error 1 > make.exe: Target `check' not remade because of errors. > > The reason for this can be found in tests/Makefile.am. There appeares the > following line: > EXTRA_PROGRAMS = tstgettext cake > > That line must look like this: > EXTRA_PROGRAMS = tstgettext$(EXEEXT) cake$(EXEEXT) Thanks for the suggestion. It looks like an automake bug to me. I've put in a workaround that will cause the Makefile line to look as you suggest. > Please note that there are probably more issues that must/should be fixed > like this: > XGETTEXT = ../src/xgettext > > Probably the above line should look like this: > XGETTEXT = ../src/xgettext$(EXEEXT) I don't think so; XGETTEXT is used for calling only, not for dependencies. And you can perfectly well call the ../src/xgettext.exe program by using the command "../src/xgettext". > 4) ./djgpp/config.bat and ./djgpp/edtests.bat > Last but not least the whole package can *not* configured at all because > the batch files are distributed with UNIX style EOL instead of MSDOS style > EOL. command.com ***refuses*** to run such batch files. It always issues > the error message: > command or file not found. > This is very confusing, especially for newbes. The file can be seen, it can > be edited but it can not be started. command.com simply refuses to execute it. > IMHO, all MSDOS batch files in a GNU distribution should be converted to > MSDOS style EOL or they are simple useless. Done. Thanks here as well. Btw, why wouldn't djtar take care of this? > I submite a patch that will change the following files: > ./djgpp/config.site > ./djgpp/README.in Applied. > ./m4/gettext.m4 > ./po/Makefile.in.in > ./tests/Makefile.am Fixed differently. Bruno