bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gettext-0.11.1 -- configure/make deficiencies (bugs)


From: Bruno Haible
Subject: Re: gettext-0.11.1 -- configure/make deficiencies (bugs)
Date: Fri, 15 Mar 2002 20:10:29 +0100 (CET)

Peter Breitenlohner writes:

> 2. One of the tests (msgunfmt-3) fails when run outside the
> sourcetree (VPATH).

Thanks for the patch, your fix is perfect.

> 3. I tried to run
>       make DESTDIR=<some_where> all check install
> but then all 18 rpath-tests failed. I tried to fix this but without sucess.

DESTDIR is meant to influence only the installation phase. A way that
works fine is

        make all check ; make install DESTDIR=<some_where>

I cannot make "make check DESTDIR=<some_where>" work, because to do
that I'd need to override DESTDIR to empty while running the rpath
tests. But the way DESTDIR is passed from one make process to another
is not formally defined, i.e. anything I could do here would be
unportable.

> In my attemts to fix this I had modified tests/Makefile.am, but then
> configure/make complained that I need to update automake (from my current
> version 1.6 to what???), this seems to be an automake-1.4/1.6
> incompatibility.

gettext is built using automake-1.5. You need automake-1.5 in order to
rebuild the Makefile.in.

> 4. I have emacs and automake installed with --prefix=/usr/local, but wanted
> to install gettext with --prefix=/usr. This just didn't work in two respects:
> 
> (a) gettext's files were installed in /usr/share/aclocal/ and not in
> /usr/local/share/aclocal/ where automake will look for them
> 
> (b) the files po-mode.el and po-mode.elc were installed in
> /usr/share/emacs/site-lisp/ and not in /usr/local/share/emacs/site-lisp/
> where emacs will look for them.

There's no standard way to make this work.

The easiest for you is to make a symlink from
/usr/share/emacs/site-lisp/ to /usr/local/share/emacs/site-lisp/,
or a symlink from /usr/local to /usr :-)

It's not possible for a program that is built with --prefix=/usr/local
to modify files in /usr/share. Nor is it desirable; the role of the
prefix is precisely to isolate all possible damage of the freshly
built version in a particular directory.

> This is really BAD. I always had the impression that the choice between
> --prefix=/usr/local and --prefix=/usr can be made for each package
> independently!

That's not the reality.

Bruno



reply via email to

[Prev in Thread] Current Thread [Next in Thread]