*** Bug 322663 has been marked as a duplicate of this bug. ***

*** Bug 322875 has been marked as a duplicate of this bug. ***

*** Bug 322876 has been marked as a duplicate of this bug. ***

*** Bug 322878 has been marked as a duplicate of this bug. ***

*** Bug 322847 has been marked as a duplicate of this bug. ***

*** Bug 322659 has been marked as a duplicate of this bug. ***

This affects many modules and has been confirmed before.

OK. I have no idea why this is happening. I need a lot more info. I need to know
the PATH and ACLOCAL_FLAGS variables that configure has. I just tried mixing
0.34.1 with a CVS install, and everything still works fine here. How can I
duplicate this? A simple run of autogen.sh doesn't do it.

ok, I can reproduce with

 $ jhbuild buildone -a at-spi

using the Gnome 2.12 module set.

...
config.status: executing po/stamp-it commands
config.status: error: po/Makefile is not ready.
*** error during stage configure of at-spi: could not configure module *** [1/1]


nazgul@demonhide:~$ echo $PATH
/opt/jdk1.5.0_04/bin:/opt/gnome2/bin:/opt/gnome2/sbin:/usr/local/bin:/usr/bin:/
bin:/usr/bin/X11:/usr/games:/home/nazgul/bin

nazgul@demonhide:~$ echo $ACLOCAL_FLAGS
-I /opt/gnome2/share/aclocal

$ which intltoolize
/opt/gnome2/bin/intltoolize

stupid me, that is a different issue.

so, finally this his how to reproduce:

 nazgul@demonhide:~$ jhbuild buildone -a procman



*** Installing procman *** [2/34]

make   install
Making install in po
make[1]: Entering directory `/multimedia/cvs/gnome2/procman/po'
make[1]: install_sh@: No se encontró el programa



 $ intltoolize --version
intltoolize (GNU intltool) 0.34.1

$ jhbuild buildone -a gdl

also reproduces

OK. Well, that one is an at-spi bug. It's calling AC_PROG_INTLTOOL in
configure.in, but the bits to use AM_GLIB_GNU_GETTEXT are commented out, and the
AC_OUTPUT section, does not include po/Makefile.in.

install_sh = /home/dobey/Projects/procman/install-sh

Well. Looks like procman works here too... What version of autoconf are you using?

And gnome-backgrounds also works for me. I'm inclined to say that this is a
problem with jhbuild, and not intltool.

autoconf (GNU Autoconf) 2.59

I haven't changed or updated jhbuild in weeks, but I upgraded intltool
shortly before the errors.

If you still think this is jhbuild, then please reassign.

I don't use jhbuild but cvsgnome and see the same errors. That's why I initially
reported this bug. So, since this happens with jhbuild and my very own cvsgnome
script. This seem to be more an intltool issue rather than a buildscript one.

The infrastructure of CVSGnome can be seen here:

http://www.akcaagac.com/index_cvsgnome.html

Oh, and my script hasn't changed since (11-08-2005), so you can imagine that I
build GNOME a dozen times meanwhile till I hit the problem recently.

Well. The build scripts not changing is of little consequence. A change in a
number of other packages could expose a problem in the build scripts.

I don't use either, and I am unable to reproduce the problem on two machines
with intltool CVS.

And, I can't reproduce the problem with builddir != srcdir with gnome-common and
intltool both installed from HEAD. I've no idea what else it could be. 

<thos> dobeywork, yes it seems to autogen fine outside of jhubild

As it does for me. I'm reassigning this to jhbuild then. I can't reproduce the
problem outside of it. If someone can reproduce the problem without jhbuild,
cvsgnome, or some other similar build script, and with straight ./autogen.sh,
then please reassign back to intltool with more info.

For one of the problem modules, could you do a "make distclean", and then do
"jhbuild buildone -a modulename".  Then attach a copy of the config.log file
that gets generated?

Created attachment 55665 [details]
log of jhbuild for procman

Created attachment 55666 [details]
config.log from jhbuild run on procman

This looks like an intltool bug.

Rodney: I see that you use @install_sh@ in intltool's Makefile.in.in.  Where do
you expect that substitution to be defined?  It doesn't get defined anywhere in
your M4 macro.

Autoconf does define an @INSTALL@ substitution.  Perhaps that's what you
intended to use instead?

More info: automake's AM_PROG_INSTALL_SH macro will define @install_sh@, and is
called by AM_INIT_AUTOMAKE.

This does not occur with procman because it is using Automake-1.4, which does
not define the variable.

Can someone check to see if any of the affected modules are not using
automake-1.4? (you can check this by reading the first few lines of the
generated toplevel Makefile.in).

If they are all automake-1.4 holdouts, then there are two ways of interpreting
this bug:
 1) intltool should work with automake-1.4 but doesn't.
 2) intltool requires a newer version of automake, so the problem modules
    should be updated.

If intltool is meant to work in the absense of automake, then the bug would
almost definitely be (1).  If it is (2), then intltool should be checking the
automake version (not sure of the best way to do that).

I checked the following (procman, gnome-mag, memprof, gnome-background,
nautilus-vcs) and all have " automake 1.4-p6" on the first line of the Makefile.in.

Okay then.  Back to dobey.

For reference, the @install_sh@ variable seems to have remained unexpanded in
those modules for a long time.  The problem only reared its head when
@install_sh@ started getting used recently:

  1.2  (dobey 04-Nov-04): install_sh = @install_sh@
  1.14 (dobey 24-Nov-05): # Automake >= 1.8 provides @mkdir_p@.
  1.14 (dobey 24-Nov-05): # Until it can be supposed, use the safe fallback:
  1.14 (dobey 24-Nov-05): mkdir_p = $(install_sh) -d

This is very disturbing. I just did a find for all the "Makefile" in the source
directory where I build Gnome 2.12.2 "grep"ing for strings "@[^ ]@" indicating
unresolved variables. There are a lot of them. This is incredible. What's going on?

sorry. "grep"ing for strings "@[^ ]*@" to indicate the unresolved variables.
There was typo ;-(

any body successful in resolving this blocker?

at-spi seems to have this problem too, but it requires automake 1.7 (!)

at-spi (automake 1.7) builds fine here with jhbuild and intltool 0.34.1.
But procman (automake 1.4) does not.


I added
 REQUIRED_AUTOMAKE_VERSION=1.7 
to the last line of autogen.sh in the procman top dir, and then it
seems to work. No error.
I have not tested if all other modules can be shifted easily to a newer version 
(though I think it makes sense, but not sure), but this still is just a 
workaround.

I reverted the changes and made gnome-autogen.sh default to automake 1.9.
at-spi, procman and gdl all build fine now.

I encourage you to set
 REQUIRED_AUTOMAKE_VERSION=${REQUIRED_AUTOMAKE_VERSION:-1.9}

in gnome-autogen.sh and see if it breaks any modules.

Bill: at-spi has a different problem. See comment #12 in this same bug. You have
translations disabled, but only partially.

Everyone else: I'm not sure how to fix this for automake 1.4. I think the fact
that automake 1.4 is still being used, is due to people not updating their
autogen.sh to require 1.5 or newer, and the fact that gnome-common defaults to
it. Frankly, I think it's time we stop using 3 year old build tools, when there
are much newer and actively maintained versions available. Outside of copying
the macros to do the new stuff that newer automakes handle, into intltool
directly, there isn't really any easy way to solve this. We need to move people
off of 1.4. I think we should change gnome-common to default to the latest
released version of automake, and people who really need 1.4, can specify that
they need 1.4. What do you think James? Can we make gnome-common default to the
new versions, and then push people to fix bugs and breakage in their modules? I
don't even have automake 1.4 installed any more. We no longer ship it in NLD at
least. I don't think I've installed it on any of my slackware machines either.

Before changing the default requested version, I'd want to do one of the following:
 * convert all Gnome desktop and developer platform modules to newer automake
 * make the remaining 1.4-using modules explicitly request that version.

One of these would be necessary to keep everything building during the transition.

That is not a full solution to this bug though.  It would probably help to make
the intltool autoconf macro check what automake version is being used, and fail
if it is too old.  You could do that with something like this:
  case "$am__api_version" in
    1.[01234])
      AC_MSG_ERROR([Intltool does not support Automake 1.4. etc])
      ;;
    *)
      ;;
  esac

Also, there is one error in your previous comment: Automake 1.4 is actually
closer to being 7 years old -- the 3 year old version of Automake is now 1.7. 
Of course, this makes it sound even worse ...

I have built the Gnome-2-12 branch (except Evolution*) and found out that the 
workaround seems to work and it does not break any 2.12 modules.

This also plays along nicely with Bug #305641.

I am attaching a suggested patch for gnome-common's gnome-autogen.sh.

Created attachment 55873 [details] [review]
default to automake 1.9 instead of 1.4

Christian: are you saying that you were able to successfully run "make
distcheck" on the automake-1.4 modules in Gnome 2.12 with this patch applied?

If you have not done that, then you have not checked to see whether it breaks
things.

No, I was running "jhbuild build" on almost all modules (except Evolution*).

But I will have a script run "make distcheck" in every module dir now that does 
not specify "REQUIRED_AUTOMAKE_VERSION=" in autogen.sh, i.e. the automake 1.4 
modules.

To help push this along, I updated libgtop and procman to Automake 1.9 today. 
While they both built with modern Automake, neither successfully distchecked
without some extra effort.

This discussion is getting a bit off topic for this particular bug though. 
Please subscribe to bug 323868 if you want to continue the discussion.

I'm lowering the priority on this. It is not in a released version of the
package, and I've implemented jamesh's suggestion for checking the version of
automake in intltool.m4, in CVS. I'm leaving this bug open though, as it would
be nice if we could work with automake 1.4 again in some way. It needs to be
investigated a bit though.

*** Bug 322586 has been marked as a duplicate of this bug. ***

*** Bug 322584 has been marked as a duplicate of this bug. ***

*** Bug 336694 has been marked as a duplicate of this bug. ***

Rodney, had this changed in the last 18 months? You still plan to support automake 1.4, or are we to OBSOLETE this bug?

I think it's safe to obsolete it now.