297544 - require autoconf 2.13

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[John Vandenberg]

At the moment, only autoconf 2.13 is usable to process configure.in.  This
probem is being tracked in bug 104642, and it looks like it will take a lot of
effort to support later versions of autoconf.  It would be nice to see that
later versions of autoconf bomb out in a similar fashion as AC_PREREQ prevents
earlier versions being used.

Steps to reproduce:
1. install autoconf 2.59
2. run autoconf 2.59 in the mozilla/ directory

Expect results:
autoconf complains that the wrong version is being used

Actual results:
autoconf attempts to process the mozilla configure.in, outputting the following
following, which is not indicative of the real problem.

configure.in:628: error: possibly undefined macro: AS_BIN
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.in:634: error: possibly undefined macro: AS_DASH_C_FLAG
configure.in:1039: error: possibly undefined macro: AS_PERL
configure.in:6858: error: possibly undefined macro: AC_OUTPUT_SUBDIRS

Comment 1

[John Vandenberg]

Attachment: v.1 - test autoconf version is 2.13

This patch catches all versions available on ftp.gnu.org, inc. 2.10, and cvs. 
It may be a good idea to use m4_include for all includes in aclocal.m4 for
consistency.

Comment 2

[Chase Phillips]

Comment on attachment 186201 [details] [diff] [review]
v.1 - test autoconf version is 2.13

This will get better review from cls who basically understands our autotools
system inside and out.	Let me hand it to him to make the call.

Comment 3

[cls]

Comment on attachment 186201 [details] [diff] [review]
v.1 - test autoconf version is 2.13

I had to move the MOZ_READ_MOZCONFIG call from altoptions.m4 into configure.in
to get this to work.  Without that change, autoconf 2.5x would exit early with
this error:
m4_defn: undefined macro: _m4_divert_diversion

Comment 4

[cls]

Attachment: v2

Comment 5

[John Vandenberg]

Comment on attachment 188306 [details] [diff] [review]
v2

Strange, I also have this error on Windows using 2.56.	Im a little concerned I
didn't hit it on Linux - I'll recheck when I get home.

Also, you may want to update the autoconf error in altoptions.m4 to use the new
m4_fatal; sorry I didnt look for those the first time.

Comment 6

[John Vandenberg]

Comment on attachment 188306 [details] [diff] [review]
v2

You can ignore my concerns in the previous comments; I needed the changes in
your patch on Linux as well.

Comment 7

[cls]

Attachment: v3

Not sure how I missed this before but moving the MOZ_READ_MOZCONFIG call into
configure.in causes the options from the mozconfig files to be ignored.  That
call must be done before the main configure.in script.

This patch moves both the MOZ_READ_MOZCONFIG & MOZ_AUTOCONF_PREREQ calls into
aclocal.m4.

Comment 8

[Serge Gautherie (:sgautherie)]

John, ping ?

Comment 9

[Justin Wood (:Callek)]

luser, ben, in the slim chance this applies, could one of you potentially pick this up?

Also popping over to Core as it originally was for Core (Suite) and not SeaMonkey

Comment 10

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.

Comment 11

[Mike Calmus]

This issue seems already to be fixed.

firefox-hg/src>make -f client.mk build
Adding client.mk options from firefox-hg/src/.mozconfig:
    MOZ_OBJDIR=$(TOPSRCDIR)/obj-$(CONFIG_GUESS)
    MOZ_CO_PROJECT=browser
firefox-hg/src/client.mk:284: *** Couldn't find autoconf 2.13.  Stop.
make: *** [firefox-hg/src/obj-x86_64-apple-darwin10.3.0/Makefile] Error 2

Comment 12

[Justin Wood (:Callek)]

(In reply to comment #11)
> This issue seems already to be fixed.

aiui, not exactly; that message seems like it couldn't find autoconf at all, whereas this bug was about having us spew an error as early as possible if a NEWER version of autoconf is used.

Comment 13

[Mitchell Hentges [:mhentges] 🦀]

We vendor and use autoconf2.13 now, this issue is obsolete.