Re: make -q and maintainer-makefile issues?

[Bruno Haible]

[Un-CCing the coreutils list.]

Charles Wilson writes:
> Apparently it can be done -- provided you configure and build in a
> specific way.

Yes, gettext can be built as documented in the INSTALL file. Only one
extra option, --with-included-libxml, is needed on Cygwin.

> However, it does not appear to be buildable the way I
> *want* to build it.
> 
> On cygwin, we typically reautotool almost any package, as a routine part
> of building it.

You are on your own when doing this. This is not the recommended
way to build, explained in the INSTALL file.

Nevertheless, the gettext package tries to help you do that: It contains
a file autogen.sh in the tarball, and it explains
  "This script requires autoconf-2.60..2.65 and automake-1.11.1 in the PATH."

> configure.ac:71: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
> detected in body
> /usr/src/packages/autoconf/26/autoconf2.5-2.68-1/src/autoconf-2.68/lib/autoconf/lang.m4:194:
>  AC_LANG_CONFTEST is expanded from...

It is absolutely normal that, when you attempt to use newer autoconf or automake
versions than the ones listed, you have to do some legwork - either by yourself
or by picking the corresponding updates from the git repository of gettext.

> Now, concerning 0.18.1.1, I have run into this "warning:
> AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body" issue before,
> with other packages; I know how to fix it -- but it requires editing a
> bunch of m4 files.  It's a PITA.

Or use a version of autoconf that is not newer than the release. Or pick the
updates from the gettext git repository.

> it ignored my --with-libncurses-prefix and linked against the wrong 
> libncurses...

This would be a bug, to be reported to bug-gettext, with enough details to
let me reproduce it.

> I wanted the java stuff built as a .jar, not an .exe, so I did
> --disable-native-java (but NOT --disable-java), but...no .jar.

The ability to build this jar depends on a Java compiler that has an
option for selecting the output format (version of class file format).
GCJ does not have this option; it's registered in the GCC bug tracker.
The OpenJDK can be used instead in general; but I haven't tested
that on Cygwin.

> libgettextlib did link, successfully, against libncurses. I can
> only assume that, simply by luck, libgettextlib doesn't actually
> reference any of the DATA items exported by the libncurses DLL:
>       BC DATA
>       PC DATA
>       SP DATA
>       UP DATA
>       ospeed DATA
>       _nc_* stuff (these are internal symbols and probably
>                      should not have been exported; call it
>                      a upstream ncurses bug)

Correct.

> another rebuild cycle (which takes forEVER on cygwin)

I understand that long rebuild cycles are painful, but one can get used to it,
and develop techniques for managing long builds. My personal approach
is to create a checklist of commands to execute and check each of the steps
once it is done. And when I make experiments, I keep all log files for later
comparison, and write down every success or failure.

Bruno