Mail Archives: djgpp-workers/2001/03/16/14:00:21
> 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
- Raw text -