Re: Bug#474901: build failure when gcj is present

[Santiago Vila]

On Sun, 8 Jun 2008, Bruno Haible wrote:

> Santiago Vila wrote:
> > Lucas Nussbaum (in the CC) has reported that gettext does not build ok
> > (does not create gettext.jar) if gcj is present.
> 
> You may be misunderstanding something: gettext would not build ok if it did
> not build and install libintl.jar. But gettext.jar is only an auxiliary set
> of tools for the 'msginit' and 'msgunfmt' programs. If gcj is present, the
> configuration and Makefiles prefer to build native executables:
> 
>   if test -n "$HAVE_GCJ" && test "$JAVA_CHOICE" = yes; then
>     BUILDJAVAEXE=yes
>   else
>     BUILDJAVAEXE=no
>   fi

Ok, is there a way to define JAVA_CHOICE from the ./configure script?
My problem boils down to that.

> > I could add a Build-Conflicts: gcj to the source package to tell
> > autobuilders not to install gcj when building gettext, but I don't
> > think it would be a good fix.
> 
> No; instead declare it ok if the package creates and installs two programs
> 'gnu.gettext.DumpResource' and 'gnu.gettext.GetURL' instead of 'gettext.jar'.

That would be against one of the desired goals, which is that the package
builds the same regardless of gcj being present at build time or not.

(Another desired goal is that the package does not depend on libgcj).

Perhaps I should explain how this problem arosed: Our source packages are
compiled by a lot of machines caled autobuilders (at least one for every
supported architecture). To build a package from source, they start
from a very minimal set of packages (called build-essential). Then they
install the build-dependencies listed in the debian control file.

Recently, however, some people started an interesting experiment using
a server farm, which is to install a lot more packages than those
listed in the build-depends field in the debian control file (as far
as those packages are not also listed in a build-conflicts field),
to verify that the packages still build, and that the binary packages
are still the "same" package. Our policy states that packages should
not build differently if more packages than those in the build-depends
are installed at build time, but the current gettext debian package did not
comply with this.

So, to summarize: Is there a way to tell the gettext build system to
behave as if gcj was not installed, even if it was?

Thanks.