After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 312125 - gnome-autogen.sh confused when installed in non-standard prefix
gnome-autogen.sh confused when installed in non-standard prefix
Status: RESOLVED FIXED
Product: gnome-common
Classification: Core
Component: general
git master
Other Linux
: High normal
: ---
Assigned To: Gnome Common Maintainer(s)
Gnome Common Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2005-07-31 09:08 UTC by Nickolay V. Shmyrev
Modified: 2005-08-16 11:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Nickolay V. Shmyrev 2005-07-31 09:08:33 UTC
Original report from Jules Colding <colding omesc com>

Hi,

I have installed gnome-common from cvs into $HOME/opt and added
$HOME/opt/bin to the start of $PATH with the ultimate goal of building
evolution from cvs. 

First I have to build gal. The build stops before it gets going. It goes
like this:

colding omc-2 ~/work/src/GNOME_CVS/gal $ ./autogen.sh
--prefix=/home/colding/opt/evolution
checking for autoconf >= 2.53...
  testing autoconf2.50... not found.
  testing autoconf... found 2.59
checking for automake >= 1.6...
  testing automake-1.6... found 1.6.3
checking for libtool >= 1.4.3...
  testing libtoolize... found 1.5.18
checking for glib-gettext >= 2.2.0...
  testing glib-gettextize... found 2.6.3
checking for intltool >= 0.25...
  testing intltoolize... found 0.31.2
checking for pkg-config >= 0.14.0...
  testing pkg-config... found 0.15.0
checking for gtk-doc >= 1.0...
  testing gtkdocize... found 1.3
Checking for required M4 macros...
Checking for forbidden M4 macros...
Processing ./configure.in
Running libtoolize...
Running glib-gettextize... Ignore non-fatal messages.
Copying file mkinstalldirs
Copying file po/Makefile.in.in

Please add the files
  codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4
  progtest.m4
from the /usr/share/aclocal directory to your autoconf macro directory
or directly to your aclocal.m4 file.
You will also need config.guess and config.sub, which you can get from
ftp://ftp.gnu.org/pub/gnu/config/.

Running intltoolize...
patching file po/Makefile.in.in
Running gtkdocize...
Running aclocal-1.6...
Running autoconf...
Running autoheader...
Running automake-1.6...
Running ./configure --enable-maintainer-mode
--prefix=/home/colding/opt/evolution ...
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk

<snip>

checking whether the g77 linker (/usr/x86_64-pc-linux-gnu/bin/ld -m elf_x86_64)
supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking for ANSI C header files... (cached) yes
./configure: line 21225: syntax error near unexpected token `yes'
./configure: line 21225: `GNOME_COMPILE_WARNINGS(yes)'


What have I done wrong?

Thanks,
  jules
Comment 1 Nickolay V. Shmyrev 2005-07-31 09:10:20 UTC
Actually, in old days gnome-autogen include it's prefix in aclocal flags, now it
just ignores it and tries only standard aclocal path. I think this situation
shoudl be corrected. It either should install macros in standard path or add
-I/prefix/share/aclocal to aclocal flags.

Comment 2 Nickolay V. Shmyrev 2005-07-31 09:11:10 UTC
And, at least it should check version of gnome macros, because in the case above
old macros was found and no sensible feedback was generated.
Comment 3 Christian Kirbach 2005-08-01 08:53:41 UTC
Then I believe the old behaviour should be put back in place :)

I think it really should add $prefix/share/aclocal to the AC_LOCAL_FLAGS .
Comment 4 James Henstridge 2005-08-03 16:02:48 UTC
Altering environment variables like ACLOCAL_FLAGS from within gnome-autogen.sh
led to all kinds of problems when rebuilding packages.  The following would break:
 1. check out module
 2. run autogen.sh
 3. run make
 4. wait for someone to check in a change to configure.in
 5. run "cvs update"
 6. run make

Things would bomb out on (6) because $ACLOCAL_FLAGS didn't include a directory
that was present at (2).  By not modifying $ACLOCAL_FLAGS, steps (2) and (6)
will either both succeed or both fail.

gnome-autogen.sh could probably do a better check for this kind of error though.
Comment 5 James Henstridge 2005-08-16 11:03:47 UTC
gnome-autogen.sh will now exit earlier if GNOME_COMPILE_WARNINGS (and a few
other gnome-common macros) are used but the macro files can't be found.