At the same time, some packages specify that they want a specific version of automake (say, 1.9).

Imagine automake-1.11 is the one installed by default (ie: /usr/bin/automake, /usr/bin/aclocal, etc are 1.11).  You set ACLOCAL='aclocal -I /some/path' and try to run automake-1.9.  It will try to use /usr/bin/aclocal which is version 1.11.  That probably won't work.

See http://lists.gnu.org/archive/html/automake-patches/2010-11/msg00089.html

jhbuild sets ACLOCAL_FLAGS in config.py when the build environment is entered. It sets the variable to the system-wide directory containing the .m4 files. When the ACLOCAL_FLAGS variable are not set, the system-wide directory is not seen by aclocal which causes strange errors. Such as:

configure.in:151: error: possibly undefined macro: AM_DISABLE_STATIC
configure.in:164: error: possibly undefined macro: AM_PROG_LIBTOOL

Older versions of jhbuild didnt automatically add the directory so you had to add addpath('ACLOCAL_FLAGS', '/usr/share/aclocal/') to .jhbuildrc. Now you don't, which imho is an improvement.

How would you like to progress this bug? What problems can you see caused by ACLOCAL_FLAGS?

I think the solution to this is to wait until automake-1.12 is out and switch to using ACLOCAL_PATH instead.

I was poking through the automake NEWS file and it seems that ACLOCAL_PATH made it into last month's 1.11.2 release.  We should definitely be using that now instead of ACLOCAL_FLAGS.

I spent the past couple of weeks pinging around.  automake 1.11.3 is now released and in Debian unstable, Fedora 17 and Ubuntu precise.  That means ACLOCAL_PATH will be available on the systems of the vast majority of people using jhbuild in the very near future.

I think it's time that jhbuild grew support for this...

Created attachment 207000 [details] [review]
config: set ACLOCAL_PATH

automake 1.11.2 supports ACLOCAL_PATH.  This will eventually allow us to
drop our use of ACLOCAL_FLAGS (which causes us much awkwardness).

For now, we support both.

Created attachment 207001 [details] [review]
drop ACLOCAL_FLAGS support

We now depend on ACLOCAL_PATH to work, giving us a de-facto dependency
on automake 1.11.2 or newer.

Created attachment 207002 [details] [review]
drop ACLOCAL_FLAGS support

We now depend on ACLOCAL_PATH to work, giving us a de-facto dependency
on automake 1.11.2 or newer.

Review of attachment 207002 [details] [review]:

When we talked about this you said you were going to keep ACLOCAL_FLAGS.  I'd really prefer to wait a cycle before introducing a new bleeding edge dependency.  The main point of jhbuild for GNOME is so people can develop against released distributions.

(In reply to comment #11)
> When we talked about this you said you were going to keep ACLOCAL_FLAGS.

I agree entirely.  That's why I did two separate patches -- one to apply now and one to hold off on until later.

I think there is nothing preventing us from introducing the first patch at this point.

Review of attachment 207000 [details] [review]:

One minor comment, otherwise looks good.

::: jhbuild/commands/sanitycheck.py
@@ +28,3 @@
 def get_aclocal_path():
+    path = os.environ.get('ACLOCAL_PATH', '').split(':')
+    path.remove('') # in case ACLOCAL_PATH was empty

path = filter(lambda x: x != '', path)

is more robust against e.g. ACLOCAL_PATH=::foo which would have multiple ''

filter and lambda are cool, but let's do list comprehensions.

Created attachment 207476 [details] [review]
config: set ACLOCAL_PATH

automake 1.11.2 supports ACLOCAL_PATH.  This will eventually allow us to
drop our use of ACLOCAL_FLAGS (which causes us much awkwardness).

For now, we support both.


Updated patch to use a comprehension, as suggested.

Comment on attachment 207476 [details] [review]
config: set ACLOCAL_PATH

Attachment 207476 [details] pushed as b89b1be - config: set ACLOCAL_PATH

Is there any reason why ACLOCAL_PATH has less paths than ACLOCAL_FLAGS? More specifically, the system path /usr/share/aclocal and /usr/local/share/aclocal are missing.

Without those, autoreconf still fails, since jhbuild relies on system for things like libtool and friends.

There is a hack in jhbuild for autoreconf case, discussed in bug 590064. But that hack is incomplete, hence I reopened that bug. If we set ACLOCAL_PATH correctly though, and depend on newer automake, this will solves it.

ACLOCAL_PATH is consulted in addition to the hard-coded system directories (like /usr/share/aclocal)

(In reply to comment #19)
> ACLOCAL_PATH is consulted in addition to the hard-coded system directories
> (like /usr/share/aclocal)

where is it hardcoded? somewhere in aclocal? But if automake/aclocal is provided by jhbuild (not in /usr) and not libtool (thus in /usr), then it will fail to find it. Which is the problem with autoreconf in bug 590064

That's a good point.  That's the basis of my suggestion for encouraging people to never run 'jhbuild bootstrap', and if we have them do so, to install all packages (ie: so that the m4 macros that we depend on are all installed into jhbuild's "system" aclocal dir)

(In reply to comment #21)
> That's a good point.  That's the basis of my suggestion for encouraging people
> to never run 'jhbuild bootstrap', and if we have them do so, to install all
> packages (ie: so that the m4 macros that we depend on are all installed into
> jhbuild's "system" aclocal dir)

agreed, we can't really have the current situation where some of the bootstrap modules are installer. It is somehow ugly, and it causes headache. I would be also in favour of all (if really desired, manually) or nothing by default.

(In reply to comment #22)

> agreed, we can't really have the current situation where some of the bootstrap
> modules are installer. It is somehow ugly, and it causes headache. I would be
> also in favour of all (if really desired, manually) or nothing by default.

That is bug 656818. I updated bug 656818's title from 'remove bootstrap' to 'make bootstrap all or nothing'.

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

Created attachment 294751 [details] [review]
autotools: finish killing off ACLOCAL_FLAGS

The time has come...

When submitting patches like this, can you specify the level of testing you've done?

Basically at this point we're relying on automake-1.12 being universal?  FWIW build.gnome.org still uses jhbuild on RHEL6, but we're in the middle of upgrading the server to RHEL7, so I may stop caring about RHEL6 jhbuild myself.

(With RHEL6:

 walters@spinner:~$ cat /etc/redhat-release 
 Red Hat Enterprise Linux Server release 6.6 (Santiago)
 walters@spinner:~$ rpm -q automake
 automake-1.11.1-4.el6.noarch
)

(In reply to comment #26)
> When submitting patches like this, can you specify the level of testing you've
> done?

I did a full rebuild of the default moduleset on Jessie.

I'm happy to hold off on this until you don't care about RHEL 6 anymore.

Attachment 294751 [details] pushed as 62a9cd1 - autotools: finish killing off ACLOCAL_FLAGS