Trunk r117046 fails on systems with older automake

Trunk r117046 fails on systems with older automake

[Andy Moreton]

Hi,

In trunk r117046 changes were made which assume that automake 1.13 is
present, but configure.ac still contains AM_INIT_AUTOMAKE(1.11).

These changes broke the build for me on mingw, as my mingw installation
only has automake 1.11 (I have not yet investigated newer versions).

If the minimum toolchain required has been changed, please make this
change more visible.

    AndyM

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Sun, 04 May 2014 13:01:22 +0100
> 
> In trunk r117046 changes were made which assume that automake 1.13 is
> present, but configure.ac still contains AM_INIT_AUTOMAKE(1.11).

Which change requires a newer Automake?  I have 1.11, and I've just
reconfigured and rebuilt the latest trunk with no problems I could
spot.  Can you show the details of your failure?

> These changes broke the build for me on mingw, as my mingw installation
> only has automake 1.11 (I have not yet investigated newer versions).
> 
> If the minimum toolchain required has been changed, please make this
> change more visible.

Indeed.  Moreover, please don't require different versions for the
trunk and the branch, as it's a nuisance to have more than a single
version installed.  Also, nt/INSTALL and/or the packaged Autotools it
points to need to be updated once we upgrade to some newer version, so
please explicitly announce that here.

Re: Trunk r117046 fails on systems with older automake

[Glenn Morris]

Eli Zaretskii wrote:

> Indeed.  Moreover, please don't require different versions for the
> trunk and the branch, as it's a nuisance to have more than a single
> version installed.

Why would you need two versions?
You can use automake 1.14 today even if the minimum is 1.11.
I'm sure many people do.
(I see I used automake 1.14 and autoconf 2.69 for 24.3.90.)

>  Also, nt/INSTALL and/or the packaged Autotools it points to need to
> be updated once we upgrade to some newer version, so please explicitly
> announce that here.

I can't promise to remember, but failues with versions older than the
minimum will be obvious, and only affect builds from bzr, not releases,
so it doesn't seem like a big deal. You can update the ezwinports
versions whenever you feel like, no need to wait for Emacs to require
them. I don't foresee the minimum versions changing any time soon, but
you never know.

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Andy Moreton <andrewjmoreton@gmail.com>,  emacs-devel@gnu.org
> Date: Sun, 04 May 2014 14:02:11 -0400
> 
> Eli Zaretskii wrote:
> 
> > Indeed.  Moreover, please don't require different versions for the
> > trunk and the branch, as it's a nuisance to have more than a single
> > version installed.
> 
> Why would you need two versions?
> You can use automake 1.14 today even if the minimum is 1.11.
> I'm sure many people do.
> (I see I used automake 1.14 and autoconf 2.69 for 24.3.90.)

At some point, 1.11 was the requirement, and newer versions would
fail.  If that is no longer the case, then I guess there's no problem.

> >  Also, nt/INSTALL and/or the packaged Autotools it points to need to
> > be updated once we upgrade to some newer version, so please explicitly
> > announce that here.
> 
> I can't promise to remember, but failues with versions older than the
> minimum will be obvious, and only affect builds from bzr, not releases,
> so it doesn't seem like a big deal.

If you can promise prominent failures, that's okay, too.  (Evidently,
at least in this case, it was not so clear-cut, for reasons we still
don't understand.)  I'm afraid of subtle failures which can go
unnoticed for a long time.

> You can update the ezwinports versions whenever you feel like, no
> need to wait for Emacs to require them.

I don't have a luxury of doing jobs that are not strictly necessary,
and don't recommend that others use versions I don't use myself, or
upgrade when there's no real need.  Besides, which version to upgrade
to? it's not like you can promise to which version we will switch
next, can you?

Re: Trunk r117046 fails on systems with older automake

[Glenn Morris]

Eli Zaretskii wrote:

> At some point, 1.11 was the requirement, and newer versions would
> fail.

I don't remember that ever happening. It would be an unusual state of
affairs.

> If you can promise prominent failures, that's okay, too.

I can promise that. autogen.sh will just say "your XX is too old".

>  (Evidently, at least in this case, it was not so clear-cut, for
> reasons we still don't understand.)

Because we did not get a proper bug report. (Juanma's mail refers to a
different issue/revision than Andy's "it doesn't work" email.)

> I'm afraid of subtle failures which can go unnoticed for a long time.

I don't think you need to be afraid of that.

> I don't have a luxury of doing jobs that are not strictly necessary,
> and don't recommend that others use versions I don't use myself, or
> upgrade when there's no real need.  Besides, which version to upgrade
> to? it's not like you can promise to which version we will switch
> next, can you?

If I were you, I would have built "most recent stable version" at the
time you built autotools, not "bare minimum that Emacs requires, even if
it's several years old". So just hop in your time machine and go back
and build a different version to start with... ;)

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: andrewjmoreton@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 04 May 2014 19:01:47 -0400
> 
> Eli Zaretskii wrote:
> 
> > At some point, 1.11 was the requirement, and newer versions would
> > fail.
> 
> I don't remember that ever happening. It would be an unusual state of
> affairs.

Yes, it was.  It's the reason why fencepost.gnu.org still has 1.11.
(I think the reason was some bug or issue with Autoconf, but my memory
is vague.  Perhaps Paul can shed more light on this.)

> > I don't have a luxury of doing jobs that are not strictly necessary,
> > and don't recommend that others use versions I don't use myself, or
> > upgrade when there's no real need.  Besides, which version to upgrade
> > to? it's not like you can promise to which version we will switch
> > next, can you?
> 
> If I were you, I would have built "most recent stable version" at the
> time you built autotools

Fortunately, you are not me.  (And I don't build a new version of
anything unless there's a really good reason to do that.  I don't have
enough free time for that.)

Re: Trunk r117046 fails on systems with older automake

[Paul Eggert]

Eli Zaretskii wrote:
> Yes, it was.  It's the reason why fencepost.gnu.org still has 1.11.
> (I think the reason was some bug or issue with Autoconf, but my memory
> is vague.  Perhaps Paul can shed more light on this.)

I expect that Fencepost is still running Automake 1.11 only because it's 
still running Trisquel 4, a distribution released in 2011 back when 
Automake 1.11 was current.  Trisquel 4 was a long-term release, was 
fully supported until last year, and is scheduled to get security 
updates through next year.  At that point I suppose even fencepost will 
have to upgrade -- one can keep dinosaurs running only for so long 
before being overwhelmed by the costs of feeding them.

I don't recall any Automake-version-related problems when building Emacs 
for a couple of years anyway, and I've been testing only with the latest 
version of Automake all along.  Perhaps there were problems before that, 
lost in the mists of time, but if so I've forgotten them.

Re: Trunk r117046 fails on systems with older automake

[Juanma Barranquero]

On Sun, May 4, 2014 at 6:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Which change requires a newer Automake?  I have 1.11, and I've just
> reconfigured and rebuilt the latest trunk with no problems I could
> spot.  Can you show the details of your failure?

Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)

Checking for autoconf (need at least version 2.65)...
ok
Checking for automake (need at least version 1.11)...
ok
Checking for pkg-config (need at least version 0.9.0)...
ok
Checking for pkg.m4...
Can't locate Automake/Getopt.pm in @INC (@INC contains:
/usr/share/automake-1.11 /usr/lib/perl5/5.8/msys /usr/lib/perl5/5.8
/usr/lib/perl5/site_perl/5.8/msys /usr/lib/perl5/site_pe
rl/5.8 /usr/lib/perl5/site_perl/5.8
/usr/lib/perl5/vendor_perl/5.8/msys /usr/lib/perl5/vendor_perl/5.8
/usr/lib/perl5/vendor_perl/5.8 .) at /c/Devel/emacs/build/bin/aclocal
line 98
4.
BEGIN failed--compilation aborted at /c/Devel/emacs/build/bin/aclocal line 984.
The version of aclocal that you are using cannot find the pkg.m4 file that
pkg-config provides.  If it is installed in some unusual directory /FOO/BAR,
set ACLOCAL_PATH='/FOO/BAR' in the environment and run this script again.

Re: Trunk r117046 fails on systems with older automake

[Andreas Schwab]

Juanma Barranquero <lekktu@gmail.com> writes:

> Can't locate Automake/Getopt.pm in @INC (@INC contains:
> /usr/share/automake-1.11 /usr/lib/perl5/5.8/msys /usr/lib/perl5/5.8
> /usr/lib/perl5/site_perl/5.8/msys /usr/lib/perl5/site_pe
> rl/5.8 /usr/lib/perl5/site_perl/5.8
> /usr/lib/perl5/vendor_perl/5.8/msys /usr/lib/perl5/vendor_perl/5.8
> /usr/lib/perl5/vendor_perl/5.8 .) at /c/Devel/emacs/build/bin/aclocal
> line 98

Your aclocal is broken.  Not our problem.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Trunk r117046 fails on systems with older automake

[Juanma Barranquero]

On Sun, May 4, 2014 at 9:39 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:

> Your aclocal is broken.  Not our problem.

"My aclocal" is just straight from Eli's automake-1.11.6-msys-bin.zip
and hasn't changed for a long while. So a recent change in the trunk
has broken my setup. Whether it is something to fix in Emacs or my
setup is another matter altogether, but I'm answering to Eli's direct
question "Can you show the details of your failure?". If you're not
interested in helping fix the problem, please at least don't
interfere.

     J

Re: Trunk r117046 fails on systems with older automake

[Paul Eggert]

Juanma Barranquero wrote:
> please at least don't interfere.

I found Andreas's remark useful and helpful, in that it narrowed the 
problem down, at least for me.  It wasn't interference.

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> Date: Sun, 04 May 2014 13:28:53 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> Juanma Barranquero wrote:
> > please at least don't interfere.
> 
> I found Andreas's remark useful and helpful, in that it narrowed the 
> problem down, at least for me.  It wasn't interference.

It could have been friendlier, though, like saying that pkg.m4 file
was the one that was absent, and where is it supposed to come from.

Re: Trunk r117046 fails on systems with older automake

[Andreas Schwab]

Juanma Barranquero <lekktu@gmail.com> writes:

> So a recent change in the trunk has broken my setup.

No, it cannot.  Your aclocal was already broken before.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Trunk r117046 fails on systems with older automake

[Andy Moreton]

On Sun 04 May 2014, Andreas Schwab wrote:

> Juanma Barranquero <lekktu@gmail.com> writes:
>
>> So a recent change in the trunk has broken my setup.
>
> No, it cannot.  Your aclocal was already broken before.

Please stop being obtuse. It does not matter whether the toolchain has a
bug or the build script: the change to trunk caused a regression.

    AndyM

Re: Trunk r117046 fails on systems with older automake

[Glenn Morris]

Hey, so please actually *give the details* of the problem that *you* see
caused by r117046.

Re: Trunk r117046 fails on systems with older automake

[Andy Moreton]

On Tue 06 May 2014, Glenn Morris wrote:

> Hey, so please actually *give the details* of the problem that *you* see
> caused by r117046.

I see exactly the same problems as Juanma and everybody else trying to
get the autotools stuff working again on Windows:

Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)

Checking for autoconf (need at least version 2.65)...
ok
Checking for automake (need at least version 1.11)...
ok
Checking for pkg-config (need at least version 0.9.0)...
ok
Checking for pkg.m4...
Can't locate Automake/Getopt.pm in @INC (@INC contains: /usr/share/automake-1.11 /usr/lib/perl5/5.8/msys /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/msys /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/msys /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at /c/emacs/mingw-devel/msys/bin/aclocal line 984.
BEGIN failed--compilation aborted at /c/emacs/mingw-devel/msys/bin/aclocal line 984.
ok
Your system has the required tools.
Running "ACLOCAL_PATH='/c/emacs/mingw-devel/share/aclocal' autoreconf -fi -I m4" ...
configure.ac:70: error: possibly undefined macro: AS_ECHO
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:1351: error: possibly undefined macro: PKG_PROG_PKG_CONFIG
configure.ac:1354: error: possibly undefined macro: PKG_CHECK_MODULES
configure.ac:1363: error: possibly undefined macro: m4_default
configure.ac:2293: error: possibly undefined macro: PKG_CONFIG
autoreconf: /usr/bin/autoconf-2.68 failed with exit status: 1


This all seems to be caused by the crazy mixture of tools required to
get a native Win32 emacs built. The notes in nt/INSTALL are very useful
but it is still quite some way from there to having a working toolchain.

    AndyM

Re: Trunk r117046 fails on systems with older automake

[Glenn Morris]

Andy Moreton wrote:

> On Tue 06 May 2014, Glenn Morris wrote:
>
>> Hey, so please actually *give the details* of the problem that *you* see
>> caused by r117046.
>
> I see exactly the same problems as Juanma and everybody else trying to
> get the autotools stuff working again on Windows:

This is completely unrelated to r117046.

> Checking for pkg.m4...
> Can't locate Automake/Getopt.pm in @INC (@INC contains: /usr/share/automake-1.11 /usr/lib/perl5/5.8/msys /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/msys /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/msys /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at /c/emacs/mingw-devel/msys/bin/aclocal line 984.
> BEGIN failed--compilation aborted at /c/emacs/mingw-devel/msys/bin/aclocal line 984.

I interpret this to mean that your aclocal prints "Can't locate
Automake/Getopt.pm in @INC" and exits with an error when called as
`aclocal --print-ac-dir'. I don't know what else to say, other than this
means your aclocal is broken, as has already been stated. Presumably it
was always broken in this way, but it never showed up till now (because
it was never called with that option before).

You need to get it working somehow, and then teach it where the pkg.m4
file that pkg-config provides is installed, if it cannot figure it out
itself.

Re: Trunk r117046 fails on systems with older automake

[Stephen J. Turnbull]

Glenn Morris writes:

 > I interpret this to mean that your aclocal is broken

It's not *his* aclocal, as several people have reported the same
behavior.  It's unlikely that all of these users have made the same
unfortunate change, instead it's likely that the various upstreams are
experiencing a coordination failure.

The responsibility for such coordination lies with Emacs in the end,
not with the users.

 > You need to get it working somehow, and then teach it where the
 > pkg.m4 file that pkg-config provides is installed, if it cannot
 > figure it out itself.

Oh, the irony of it all! given that autoconf and friends are supposed
to do that figuring out, and do it *portably*.[1]

More specifically, from a quick look at configure.ac, it is clear that
program does not consider pkg-config to be a hard requirement of Emacs
(and INSTALL doesn't say so, although INSTALL.REPO does).  ISTM that
configure should test for a working pkg-config, and warn the user
about breakage at that point (preferably with useful advice for a
remedy).  Blowing up in the middle of a test for an unrelated feature
that happens to use pkg-config is not user-friendly.

A review of configure (trunk updated from bzr today, I assume bzr is
still current?) suggests that Emacs should be buildable with no
pkg-config at all, you'll just be missing a pile of features.

Patches welcome, I know.  Sorry, not high on my priority list.


Footnotes: 
[1]  That's the excuse for the whole insanely complicated mess!

Re: Trunk r117046 fails on systems with older automake

[Paul Eggert]

Stephen J. Turnbull wrote:
> More specifically, from a quick look at configure.ac, it is clear that
> program does not consider pkg-config to be a hard requirement of Emacs
> (and INSTALL doesn't say so, although INSTALL.REPO does).

The distinction here is building from an Emacs distribution tarball 
(which is what INSTALL is about) and building from the repository (which 
is what INSTALL.REPO is about).  pkg-config is a requirement of the 
latter, not the former.

The assumption is that people building from the repository are expert 
enough to use the extra development tools required, and to set up their 
environments so that these extra development tools work.  It shouldn't 
be rocket science, and it shouldn't be unreasonable to expect 
development tools to be installed correctly.  This particular problem 
seems isolated to Windows developers and I expect they'll work it out 
among themselves.

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> Date: Tue, 06 May 2014 19:14:49 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org
> 
> This particular problem seems isolated to Windows developers

It will happen on any system that doesn't have pkg-config installed.

Re: Trunk r117046 fails on systems with older automake

[Paul Eggert]

Eli Zaretskii wrote:
>> This particular problem seems isolated to Windows developers
> It will happen on any system that doesn't have pkg-config installed.

I was referring to the problem that Andy Moreton reported.  If 
pkg-config isn't installed, autogen.sh should fail with this diagnostic:

Your system seems to be missing the following tool(s):
pkg-config (missing)

Here the problem and fix is obvious, as Óscar Fuentes already mentioned 
when he mentioned this diagnostic: he simply installed pkg-config.  In 
contrast, Andy Moreton reported this diagnostic:

Checking for pkg-config (need at least version 0.9.0)...
ok
Checking for pkg.m4...
Can't locate Automake/Getopt.pm in @INC

This is less obvious, but the problem can't be due simply to pkg-config 
being absent, as pkg-config ran successfully.  It must be something else.

The Automake diagnostic could occur on any O.S. platform, but so far it 
appears that the only people who've reported it are Microsoft Windows 
developers.  Perhaps the installation problem, whatever it is, is more 
likely on that platform.

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> Date: Tue, 06 May 2014 21:00:42 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: stephen@xemacs.org, andrewjmoreton@gmail.com, emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> >> This particular problem seems isolated to Windows developers
> > It will happen on any system that doesn't have pkg-config installed.
> 
> I was referring to the problem that Andy Moreton reported.  If 
> pkg-config isn't installed, autogen.sh should fail with this diagnostic:
> 
> Your system seems to be missing the following tool(s):
> pkg-config (missing)

Yes, but I don't normally run autogen.sh, I run "make" (and tell other
to do that as well).

> Here the problem and fix is obvious, as Óscar Fuentes already mentioned 
> when he mentioned this diagnostic: he simply installed pkg-config.  In 
> contrast, Andy Moreton reported this diagnostic:
> 
> Checking for pkg-config (need at least version 0.9.0)...
> ok
> Checking for pkg.m4...
> Can't locate Automake/Getopt.pm in @INC
> 
> This is less obvious, but the problem can't be due simply to pkg-config 
> being absent, as pkg-config ran successfully.  It must be something else.

The diagnostic about Getopt.pm is bogus (might be an Automake bug),
the real problem is that pkg.m4 is not where it should be.

> The Automake diagnostic could occur on any O.S. platform, but so far it 
> appears that the only people who've reported it are Microsoft Windows 
> developers.

I suspect that's because (a) the rest use GNU/Linux, and (b) have
pkg-config installed.  The latter is why I didn't see any problems on
Windows.

Re: Trunk r117046 fails on systems with older automake

[Andy Moreton]

On Wed 07 May 2014, Eli Zaretskii wrote:

>> Eli Zaretskii wrote:
>> >> This particular problem seems isolated to Windows developers
>> > It will happen on any system that doesn't have pkg-config installed.
>> 
>> I was referring to the problem that Andy Moreton reported.  If 
>> pkg-config isn't installed, autogen.sh should fail with this diagnostic:
>> 
>> Your system seems to be missing the following tool(s):
>> pkg-config (missing)
>
> Yes, but I don't normally run autogen.sh, I run "make" (and tell other
> to do that as well).
>
>> Here the problem and fix is obvious, as Óscar Fuentes already mentioned 
>> when he mentioned this diagnostic: he simply installed pkg-config.  In 
>> contrast, Andy Moreton reported this diagnostic:
>> 
>> Checking for pkg-config (need at least version 0.9.0)...
>> ok
>> Checking for pkg.m4...
>> Can't locate Automake/Getopt.pm in @INC
>> 
>> This is less obvious, but the problem can't be due simply to pkg-config 
>> being absent, as pkg-config ran successfully.  It must be something
>> else.

I already had pkg-config installed, and working for use of optional
packages (gnutls, libxml2, librsvg etc) in building for wmacs-24 and
trunk before the recent changes.

In my previous setup I was keeping tools supplied form the mingw project
separated from all tools from other projects to prevent inadvertantly
overwriting DLLs with incompatible versions. The aim was to do some of
the (non-existant) package manager's work, and ensure that the toolchain
setup is repeatable.

I've now moved pkg-config and pkg.m4 under the msys tree, which seems to
make things happier. All of the rest of the libraries not sourced from
the mingw project still live in a separate tree, and the configury seems
happy with that.

    AndyM

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Thu, 08 May 2014 01:05:22 +0100
> 
> In my previous setup I was keeping tools supplied form the mingw project
> separated from all tools from other projects to prevent inadvertantly
> overwriting DLLs with incompatible versions. The aim was to do some of
> the (non-existant) package manager's work, and ensure that the toolchain
> setup is repeatable.
> 
> I've now moved pkg-config and pkg.m4 under the msys tree, which seems to
> make things happier. All of the rest of the libraries not sourced from
> the mingw project still live in a separate tree, and the configury seems
> happy with that.

I don't understand how moving things could solve this, perhaps you had
some files/programs duplicated.  FWIW, my MSYS and MinGW trees are
separate.

Anyway, is your problem solved now?

Re: Trunk r117046 fails on systems with older automake

[Andy Moreton]

On Thu 08 May 2014, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton@gmail.com>
>> Date: Thu, 08 May 2014 01:05:22 +0100
>> 
>> In my previous setup I was keeping tools supplied form the mingw project
>> separated from all tools from other projects to prevent inadvertantly
>> overwriting DLLs with incompatible versions. The aim was to do some of
>> the (non-existant) package manager's work, and ensure that the toolchain
>> setup is repeatable.
>> 
>> I've now moved pkg-config and pkg.m4 under the msys tree, which seems to
>> make things happier. All of the rest of the libraries not sourced from
>> the mingw project still live in a separate tree, and the configury seems
>> happy with that.
>
> I don't understand how moving things could solve this, perhaps you had
> some files/programs duplicated.  FWIW, my MSYS and MinGW trees are
> separate.
>
> Anyway, is your problem solved now?

Yes.

It seems that whatever I did the configury ignored the autotools from
ezwinports installed under c:/emacs/mingw-devel, and always used the
ones from c:/mingw/msys (regardles of PATH). If I uninstalled the msys
versions then autogen.sh simply failed. In addition, the generated
configure could find pkg-config, but not pkg.m4 unless it was moved into
the msys tree (I tried using ACLOCAL_PATH for this, to no avail).

Thanks,

    AndyM

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Thu, 08 May 2014 09:00:22 +0100
> 
> > Anyway, is your problem solved now?
> 
> Yes.

Great!

> It seems that whatever I did the configury ignored the autotools from
> ezwinports installed under c:/emacs/mingw-devel, and always used the
> ones from c:/mingw/msys (regardles of PATH). If I uninstalled the msys
> versions then autogen.sh simply failed. In addition, the generated
> configure could find pkg-config, but not pkg.m4 unless it was moved into
> the msys tree

Indeed, both the autotools from ezwinports and pkg.m4 should be in the
MSYS tree.  (The README file on ezwinports site explicitly says that
about Autoconf and Automake.)

Re: Trunk r117046 fails on systems with older automake

[Andy Moreton]

On 08/05/2014 4:05 PM, Eli Zaretskii wrote:
>> From: Andy Moreton <andrewjmoreton@gmail.com>
>> Date: Thu, 08 May 2014 09:00:22 +0100
>>
>> > Anyway, is your problem solved now?
>>
>> Yes.
>
> Great!
>
>> It seems that whatever I did the configury ignored the autotools from
>> ezwinports installed under c:/emacs/mingw-devel, and always used the
>> ones from c:/mingw/msys (regardles of PATH). If I uninstalled the msys
>> versions then autogen.sh simply failed. In addition, the generated
>> configure could find pkg-config, but not pkg.m4 unless it was moved into
>> the msys tree
>
> Indeed, both the autotools from ezwinports and pkg.m4 should be in the
> MSYS tree.  (The README file on ezwinports site explicitly says that
> about Autoconf and Automake.)

I missed this detail - it would be useful to note this in nt/INSTALL.

     AndyM

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> Date: Thu, 08 May 2014 16:14:05 +0100
> From: Andy Moreton <andrewjmoreton@gmail.com>
> CC: emacs-devel@gnu.org
> 
> > Indeed, both the autotools from ezwinports and pkg.m4 should be in the
> > MSYS tree.  (The README file on ezwinports site explicitly says that
> > about Autoconf and Automake.)
> 
> I missed this detail - it would be useful to note this in nt/INSTALL.

Well, nt/INSTALL mentions them in the section that describes
installation of the MSYS tools...

Re: Trunk r117046 fails on systems with older automake

[Andy Moreton]

On Wed 07 May 2014, Paul Eggert wrote:

> The assumption is that people building from the repository are expert enough
> to use the extra development tools required, and to set up their environments
> so that these extra development tools work.  It shouldn't be rocket science,
> and it shouldn't be unreasonable to expect development tools to be installed
> correctly.  This particular problem seems isolated to Windows developers and I
> expect they'll work it out among themselves.

This is exactly the problem - getting a working toolchain is
considerably more difficult on Windows. There are several sets of
incompatible toolchains, and no package manager to install anything. On
other platforms (including Cygwin) this is easy.

The build requires two distinct sets of tools (msys for autotools and
configure, mingw for building) which live in separate locations and have
different filename translation schemes from posix style naming to the
underlying Windows filesystem. On Windows installing development tools
correctly *is* hard.

It would seems from the current issues that Eli is almost the only
developer successfully building for a Windows target from trunk.

    AndyM

Re: Trunk r117046 fails on systems with older automake

[martin rudalics]

 > It would seems from the current issues that Eli is almost the only
 > developer successfully building for a Windows target from trunk.

Meanwhile I was able to successfully build trunk as well by deploying
all of

glib_2.34.3-1_win32.zip
glib-dev_2.34.3-1_win32.zip
libiconv_1.13.1-1_win32.zip
libiconv-dev_1.13.1-1_win32.zip
pkg-config_0.28-1_win32.zip
pkg-config-dev_0.28-1_win32.zip

in my msys/1.0 subdirectory.

martin

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> Date: Wed, 07 May 2014 12:13:26 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
>  > It would seems from the current issues that Eli is almost the only
>  > developer successfully building for a Windows target from trunk.
> 
> Meanwhile I was able to successfully build trunk as well by deploying
> all of
> 
> glib_2.34.3-1_win32.zip
> glib-dev_2.34.3-1_win32.zip
> libiconv_1.13.1-1_win32.zip
> libiconv-dev_1.13.1-1_win32.zip
> pkg-config_0.28-1_win32.zip
> pkg-config-dev_0.28-1_win32.zip
> 
> in my msys/1.0 subdirectory.

I hope you didn't put these into your MSYS tree, because that's wrong:
these are native programs and DLLs, not MSYS programs.  They should be
in the MinGW tree, and only the *.m4 files should be copied to the
MSYS tree.

Re: Trunk r117046 fails on systems with older automake

[martin rudalics]

 > I hope you didn't put these into your MSYS tree,

I did put them into the MSYS tree.

 > because that's wrong:
 > these are native programs and DLLs, not MSYS programs.  They should be
 > in the MinGW tree, and only the *.m4 files should be copied to the
 > MSYS tree.

So far I don't care because I can work with my builds.  As soon as
someone has a working recipe I can copy anything anywhere.  My MinGW
installation is already seven times as large as before last year's
changes so why should I care.  Obviously I don't have the slightest idea
of what I am doing and what all this is needed for.

martin

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> Date: Wed, 07 May 2014 17:45:50 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: andrewjmoreton@gmail.com, emacs-devel@gnu.org
> 
>  > I hope you didn't put these into your MSYS tree,
> 
> I did put them into the MSYS tree.
> 
>  > because that's wrong:
>  > these are native programs and DLLs, not MSYS programs.  They should be
>  > in the MinGW tree, and only the *.m4 files should be copied to the
>  > MSYS tree.
> 
> So far I don't care because I can work with my builds.

As long as you have only 1 copy of foo.exe or bar.dll on your system,
it indeed doesn't matter (except for making it easier for you to tell
which program is of what kind).  But once you have an MSYS and a MinGW
build of the same file, you cannot have them both in the same
directory.  Likewise, if foo.exe is a MinGW program and depends on a
MinGW bar.dll, but instead finds an MSYS bar.dll, you are in trouble.

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Wed, 07 May 2014 10:42:31 +0100
> 
> On Wed 07 May 2014, Paul Eggert wrote:
> 
> > The assumption is that people building from the repository are expert enough
> > to use the extra development tools required, and to set up their environments
> > so that these extra development tools work.  It shouldn't be rocket science,
> > and it shouldn't be unreasonable to expect development tools to be installed
> > correctly.  This particular problem seems isolated to Windows developers and I
> > expect they'll work it out among themselves.
> 
> This is exactly the problem - getting a working toolchain is
> considerably more difficult on Windows. There are several sets of
> incompatible toolchains, and no package manager to install anything. On
> other platforms (including Cygwin) this is easy.
> 
> The build requires two distinct sets of tools (msys for autotools and
> configure, mingw for building) which live in separate locations and have
> different filename translation schemes from posix style naming to the
> underlying Windows filesystem. On Windows installing development tools
> correctly *is* hard.

This is true (although the initial effort of establishing a working
build environment is largely a one-time thing).  However, you already
had such an environment, because AFAIK you were able to build the
trunk before.  So the only thing that was required by the latest
changes on the trunk was to install pkg-config and its macros in
pkg.m4, which doesn't sound like a catastrophe, or something too hard
to do.

Are you saying that there were additional problems, after pkg-config
was correctly set up?  If so, please describe them.

> It would seems from the current issues that Eli is almost the only
> developer successfully building for a Windows target from trunk.

There's no magic here: my MSYS/MinGW build environment is probably
more full than what you have, because I use it a lot, and have built a
lot more packages than just Emacs.  IOW, I bumped into those problems
and solved them long ago.  ("ls -l --time=c" tells me that I copied
pkg.m4 to the MSYS tree more than a year after installing pkg-config.)

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Wed, 07 May 2014 11:00:26 +0900
> Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org
> 
> Glenn Morris writes:
> 
>  > I interpret this to mean that your aclocal is broken
> 
> It's not *his* aclocal, as several people have reported the same
> behavior.  It's unlikely that all of these users have made the same
> unfortunate change, instead it's likely that the various upstreams are
> experiencing a coordination failure.
> 
> The responsibility for such coordination lies with Emacs in the end,
> not with the users.
> 
>  > You need to get it working somehow, and then teach it where the
>  > pkg.m4 file that pkg-config provides is installed, if it cannot
>  > figure it out itself.
> 
> Oh, the irony of it all! given that autoconf and friends are supposed
> to do that figuring out, and do it *portably*.[1]

Actually, nothing special is needed beyond installing pkg-config and
making sure its pkg.m4 file is in the directory where aclocal looks
for such files.

Re: Trunk r117046 fails on systems with older automake

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > From: "Stephen J. Turnbull" <stephen@xemacs.org>

 >> Oh, the irony of it all! given that autoconf and friends are supposed
 >> to do that figuring out, and do it *portably*.[1]
 > 
 > Actually, nothing special is needed beyond installing pkg-config

No problem there, since I'm sure there are packaged pkg-configs.

 > and making sure its pkg.m4 file is in the directory where aclocal
 > looks for such files.

That's the kind of thing that shouldn't be necessary IMO.

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: andrewjmoreton@gmail.com,
>     emacs-devel@gnu.org
> Date: Wed, 07 May 2014 13:48:35 +0900
> 
> Eli Zaretskii writes:
>  > From: "Stephen J. Turnbull" <stephen@xemacs.org>
> 
>  >> Oh, the irony of it all! given that autoconf and friends are supposed
>  >> to do that figuring out, and do it *portably*.[1]
>  > 
>  > Actually, nothing special is needed beyond installing pkg-config
> 
> No problem there, since I'm sure there are packaged pkg-configs.

How do you mean "packaged"?  They are just *.zip archives (not that it
isn't enough, IMO).

>  > and making sure its pkg.m4 file is in the directory where aclocal
>  > looks for such files.
> 
> That's the kind of thing that shouldn't be necessary IMO.

It cannot be avoided on Windows, because one needs to have 2
Posix-like trees: one for MSYS and another one for native MinGW
programs.

Re: Trunk r117046 fails on systems with older automake

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>

 > > No problem there, since I'm sure there are packaged pkg-configs.
 > 
 > How do you mean "packaged"?  They are just *.zip archives (not that it
 > isn't enough, IMO).

I mean cd to the right place, unzip, and you're ready to run.

 > >  > and making sure its pkg.m4 file is in the directory where aclocal
 > >  > looks for such files.
 > > 
 > > That's the kind of thing that shouldn't be necessary IMO.
 > 
 > It cannot be avoided on Windows, because one needs to have 2
 > Posix-like trees: one for MSYS and another one for native MinGW
 > programs.

So?  If you need two copies of pkg-config, install twice.  If you
don't, there should be an explanation of how to install it and then
copy/mv pkg.m4 so that the caller that needs it can find it.  It
shouldn't be Andrew's or anybody else's problem to figure these things
out (unless they have installed them already someplace other than
where README.NT or whatever is appropriate suggests).

Or, if there are no such instructions and you can't make time for a
while, ask *one* of those people to share their experience of creating
such an installation and add it to the appropriate README.  These
folks are all good citizens, I recognize their names.  They just don't
want to do redundant work to find out how to set things up if somebody
already knows how.

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: andrewjmoreton@gmail.com,
>     emacs-devel@gnu.org
> Date: Thu, 08 May 2014 04:40:07 +0900
> 
> Eli Zaretskii writes:
>  > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
> 
>  > > No problem there, since I'm sure there are packaged pkg-configs.
>  > 
>  > How do you mean "packaged"?  They are just *.zip archives (not that it
>  > isn't enough, IMO).
> 
> I mean cd to the right place, unzip, and you're ready to run.

That's correct.

>  > >  > and making sure its pkg.m4 file is in the directory where aclocal
>  > >  > looks for such files.
>  > > 
>  > > That's the kind of thing that shouldn't be necessary IMO.
>  > 
>  > It cannot be avoided on Windows, because one needs to have 2
>  > Posix-like trees: one for MSYS and another one for native MinGW
>  > programs.
> 
> So?  If you need two copies of pkg-config, install twice.

One copy of pkg-config is enough, and there's no MSYS pkg-config
binaries available (AFAIK) to become the 2nd copy.

> If you don't, there should be an explanation of how to install it
> and then copy/mv pkg.m4 so that the caller that needs it can find
> it.  It shouldn't be Andrew's or anybody else's problem to figure
> these things out (unless they have installed them already someplace
> other than where README.NT or whatever is appropriate suggests).

People should feel free to add to nt/INSTALL what they think is
necessary.  My understanding for now is that no one really knows why
things didn't work for them, and my setup, described in nt/INSTALL,
does work for me.

Re: Trunk r117046 fails on systems with older automake

[Glenn Morris]

"Stephen J. Turnbull" wrote:

> More specifically, from a quick look at configure.ac, it is clear that
> program does not consider pkg-config to be a hard requirement of Emacs
> (and INSTALL doesn't say so, although INSTALL.REPO does).

It isn't a requirement, the INSTALL docs are correct. It is like
autoconf and automake: required for builds from the repo, but not from
tarballs. As documented.

> A review of configure (trunk updated from bzr today, I assume bzr is
> still current?) suggests that Emacs should be buildable with no
> pkg-config at all, you'll just be missing a pile of features.

Emacs tarballs are buildable without pkg-config.
It is required to generate the configure script, like autoconf is.

> Patches welcome, I know.  Sorry, not high on my priority list.

Don't worry, I have zero expectation of you ever supplying a patch for
anything.

Re: Trunk r117046 fails on systems with older automake

[David Kastrup]

Glenn Morris <rgm@gnu.org> writes:

> "Stephen J. Turnbull" wrote:

[...]

>> Patches welcome, I know.  Sorry, not high on my priority list.
>
> Don't worry, I have zero expectation of you ever supplying a patch for
> anything.

And you could have had zero expectation of Stephen supplying helpful
info for a number of ongoing years on a lot of topics and contributing
his respective experience from his position as the maintainer of XEmacs,
the archnemesis of Emacs.

It's like frowning on Mahatma Gandhi since he was weaving himself the
clothes he wore to set an example for Indian self-reliance, but omitting
to cast bullets on his own.

Yes, overgrandiose example, sorry for that.  Still I consider that
Stephen deserves a bit more of "thank you" and a bit less of "screw you"
for the work he invests into keeping his competition in good shape.

-- 
David Kastrup

Re: Trunk r117046 fails on systems with older automake

[Óscar Fuentes]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> I see exactly the same problems as Juanma and everybody else trying to
> get the autotools stuff working again on Windows:

[snip]

> This all seems to be caused by the crazy mixture of tools required to
> get a native Win32 emacs built. The notes in nt/INSTALL are very useful
> but it is still quite some way from there to having a working toolchain.

I've just succesfully configured Emacs trunk with MSYS2 [1]. The
difference from the previous time I built Emacs (last December) was that
autogen.sh complained about missing pkg-config, but

pacman -S pkg-config

fixed the issue.


The build failed with

../../emacs/lib/dup2.c:38:26: fatal error: msvc-inval.h: No such file or directory
 #  include "msvc-inval.h"
                          ^
compilation terminated.

but that was probably caused by me using the latest MinGW-w64
(i686-4.9.0-release-win32-dwarf-rt_v3-rev1.7z)


[1] MSYS2: http://sourceforge.net/projects/msys2/

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 07 May 2014 03:03:13 +0200
> 
> The build failed with
> 
> ../../emacs/lib/dup2.c:38:26: fatal error: msvc-inval.h: No such file or directory
>  #  include "msvc-inval.h"
>                           ^
> compilation terminated.

lib/dup2.c is not supposed to be compiled in the MinGW build.  Check
your config.log for the reasons it is.

Re: Trunk r117046 fails on systems with older automake

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> The build failed with
>> 
>> ../../emacs/lib/dup2.c:38:26: fatal error: msvc-inval.h: No such file or directory
>>  #  include "msvc-inval.h"
>>                           ^
>> compilation terminated.
>
> lib/dup2.c is not supposed to be compiled in the MinGW build.  Check
> your config.log for the reasons it is.

The problem was that on MSYS2 (when started with the mingw_shell.bat
script) MSYSTEM contains MINGW whereas the configure script tests for
either MINGW32 or MINGW64.

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 07 May 2014 13:33:22 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The build failed with
> >> 
> >> ../../emacs/lib/dup2.c:38:26: fatal error: msvc-inval.h: No such file or directory
> >>  #  include "msvc-inval.h"
> >>                           ^
> >> compilation terminated.
> >
> > lib/dup2.c is not supposed to be compiled in the MinGW build.  Check
> > your config.log for the reasons it is.
> 
> The problem was that on MSYS2 (when started with the mingw_shell.bat
> script) MSYSTEM contains MINGW whereas the configure script tests for
> either MINGW32 or MINGW64.

Patches to accommodate MSYS2 are welcome.

Re: Trunk r117046 fails on systems with older automake

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> The problem was that on MSYS2 (when started with the mingw_shell.bat
>> script) MSYSTEM contains MINGW whereas the configure script tests for
>> either MINGW32 or MINGW64.
>
> Patches to accommodate MSYS2 are welcome.

No longer needed. Just checked that recent versions of MSYS2 set MSYSTEM
to MINGW32 on mingw32_shell.bat.

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 07 May 2014 17:38:27 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> The problem was that on MSYS2 (when started with the mingw_shell.bat
> >> script) MSYSTEM contains MINGW whereas the configure script tests for
> >> either MINGW32 or MINGW64.
> >
> > Patches to accommodate MSYS2 are welcome.
> 
> No longer needed. Just checked that recent versions of MSYS2 set MSYSTEM
> to MINGW32 on mingw32_shell.bat.

Should we say in nt/INSTALL which versions of MSYS2 are safe?  Do you
happen to know which ones are?

Re: Trunk r117046 fails on systems with older automake

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Patches to accommodate MSYS2 are welcome.
>> 
>> No longer needed. Just checked that recent versions of MSYS2 set MSYSTEM
>> to MINGW32 on mingw32_shell.bat.
>
> Should we say in nt/INSTALL which versions of MSYS2 are safe?  Do you
> happen to know which ones are?

Dunno. Just upgraded my install to the most recent versions (with pacman
-S -u). AFAIK MSYS2 has no versions proper. From time to time the
maintainer publishes a file with a date on the name containing the base
package and thereafter the user is supposed to install/upgrade the
packages he needs using the package manager (pacman). On GNU/Linux
terms, MSYS2 uses a rolling release schema.

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Wed, 07 May 2014 00:53:37 +0100
> 
> On Tue 06 May 2014, Glenn Morris wrote:
> 
> > Hey, so please actually *give the details* of the problem that *you* see
> > caused by r117046.
> 
> I see exactly the same problems as Juanma and everybody else trying to
> get the autotools stuff working again on Windows:
> 
> Checking whether you have the necessary tools...
> (Read INSTALL.REPO for more details on building Emacs)
> 
> Checking for autoconf (need at least version 2.65)...
> ok
> Checking for automake (need at least version 1.11)...
> ok
> Checking for pkg-config (need at least version 0.9.0)...
> ok
> Checking for pkg.m4...
> Can't locate Automake/Getopt.pm in @INC (@INC contains: /usr/share/automake-1.11 /usr/lib/perl5/5.8/msys /usr/lib/perl5/5.8 /usr/lib/perl5/site_perl/5.8/msys /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8/msys /usr/lib/perl5/vendor_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 .) at /c/emacs/mingw-devel/msys/bin/aclocal line 984.
> BEGIN failed--compilation aborted at /c/emacs/mingw-devel/msys/bin/aclocal line 984.
> ok
> Your system has the required tools.
> Running "ACLOCAL_PATH='/c/emacs/mingw-devel/share/aclocal' autoreconf -fi -I m4" ...
> configure.ac:70: error: possibly undefined macro: AS_ECHO
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
> configure.ac:1351: error: possibly undefined macro: PKG_PROG_PKG_CONFIG
> configure.ac:1354: error: possibly undefined macro: PKG_CHECK_MODULES
> configure.ac:1363: error: possibly undefined macro: m4_default
> configure.ac:2293: error: possibly undefined macro: PKG_CONFIG
> autoreconf: /usr/bin/autoconf-2.68 failed with exit status: 1

Do you have pkg.m4 in MSYS share/aclocal directory?  If not, does
putting that file there solve the problem?  If not, perhaps you don't
have pkg-config installed, and should install it (see my other
messages in this thread).

> This all seems to be caused by the crazy mixture of tools required to
> get a native Win32 emacs built. The notes in nt/INSTALL are very useful
> but it is still quite some way from there to having a working toolchain.

Please tell what is missing from nt/INSTALL.

Re: Trunk r117046 fails on systems with older automake

[Juanma Barranquero]

(Sorry I didn't answer before, I'm just *very* busy now.)

On Wed, May 7, 2014 at 4:53 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Do you have pkg.m4 in MSYS share/aclocal directory?  If not, does
> putting that file there solve the problem?  If not, perhaps you don't
> have pkg-config installed, and should install it (see my other
> messages in this thread).

I have pkg.m4 in the MSYS share/aclocal directory, I installed
pkg-config as required (or at least, I think so).

I get:

  Checking whether you have the necessary tools...
  (Read INSTALL.REPO for more details on building Emacs)

  Checking for autoconf (need at least version 2.65)...
  ok
  Checking for automake (need at least version 1.11)...
  ok
  Checking for pkg-config (need at least version 0.9.0)...
  ok
  Checking for pkg.m4...
  ok
  Your system has the required tools.
  Running "ACLOCAL_PATH='/usr/share/aclocal' autoreconf -fi -I m4" ...
  configure.ac:70: error: possibly undefined macro: AS_ECHO
        If this token and others are legitimate, please use m4_pattern_allow.
        See the Autoconf documentation.
  configure.ac:1352: error: possibly undefined macro: PKG_PROG_PKG_CONFIG
  configure.ac:1355: error: possibly undefined macro: PKG_CHECK_MODULES
  configure.ac:1364: error: possibly undefined macro: m4_default
  configure.ac:2294: error: possibly undefined macro: PKG_CONFIG
  autoreconf-2.68: /mingw/bin/autoconf-2.68 failed with exit status: 1

     J

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 7 May 2014 16:51:27 +0200
> Cc: Andy Moreton <andrewjmoreton@gmail.com>, Emacs developers <emacs-devel@gnu.org>
> 
>   Checking for pkg-config (need at least version 0.9.0)...
>   ok
>   Checking for pkg.m4...
>   ok
>   Your system has the required tools.
>   Running "ACLOCAL_PATH='/usr/share/aclocal' autoreconf -fi -I m4" ...
>   configure.ac:70: error: possibly undefined macro: AS_ECHO
>         If this token and others are legitimate, please use m4_pattern_allow.
>         See the Autoconf documentation.
>   configure.ac:1352: error: possibly undefined macro: PKG_PROG_PKG_CONFIG
>   configure.ac:1355: error: possibly undefined macro: PKG_CHECK_MODULES
>   configure.ac:1364: error: possibly undefined macro: m4_default
>   configure.ac:2294: error: possibly undefined macro: PKG_CONFIG
>   autoreconf-2.68: /mingw/bin/autoconf-2.68 failed with exit status: 1

Does pkg-config run from the cmd prompt, or does it show a "DLL
missing" dialog or some other failure?  Do you see any pkg-config
related error messages in config.log?

Which m4.exe do you have installed, MSYS or MinGW?  What version(s) of
them?

What do you get if you run "autoreconf -v -v --warnings=all -fi -I m4"
from the MSYS Bash promt -- do you get the same output as what I sent
(off list)?  Any errors/warnings that could hint at the problem?

FWIW, I don't use Autoconf 2.68, I use 2.65 on one machine and 2.69 on
another (the later with a newer Automake, I think).

Re: Trunk r117046 fails on systems with older automake

[Juanma Barranquero]

On Wed, May 7, 2014 at 5:32 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Does pkg-config run from the cmd prompt

I don't have MinGW or MSYS in the PATH, so they don't run from CMD.
Everything I run to build Emacs runs from the MSYS sh.exe with a path
than includes MinGW\bin and MSYS\1.0\bin, and C:\devel\emacs\build\bin
(which has many EZWinports tools).

(mdo = "c:\bin\MinGW\msys\1.0\bin\sh.exe --login -i")

  C:\> mdo pkg-config --version
  0.28

> or does it show a "DLL
> missing" dialog or some other failure?  Do you see any pkg-config
> related error messages in config.log?

No to both.

> Which m4.exe do you have installed, MSYS or MinGW?

MSYS.

> What version(s) of  them?

  C:\> mdo m4 --version
  m4 (GNU M4) 1.4.16

> What do you get if you run "autoreconf -v -v --warnings=all -fi -I m4"
> from the MSYS Bash promt -- do you get the same output as what I sent
> (off list)?  Any errors/warnings that could hint at the problem?

It fails with

  configure.ac:70: error: possibly undefined macro: AS_ECHO
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
  configure.ac:1352: error: possibly undefined macro: PKG_PROG_PKG_CONFIG
  configure.ac:1355: error: possibly undefined macro: PKG_CHECK_MODULES
  configure.ac:1364: error: possibly undefined macro: m4_default
  configure.ac:2294: error: possibly undefined macro: PKG_CONFIG
  autoreconf-2.68: /mingw/bin/autoconf-2.68 failed with exit status: 1

> FWIW, I don't use Autoconf 2.68, I use 2.65 on one machine and 2.69 on
> another (the later with a newer Automake, I think).

That hints at a problem, indeed. I seem to have two autoreconf
installed: 2.65, from EZWinports, in my C:\devel\build\bin directory,
and 2.68 in MinGW/bin.

     J

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 7 May 2014 19:18:14 +0200
> Cc: Andy Moreton <andrewjmoreton@gmail.com>, Emacs developers <emacs-devel@gnu.org>
> 
> > FWIW, I don't use Autoconf 2.68, I use 2.65 on one machine and 2.69 on
> > another (the later with a newer Automake, I think).
> 
> That hints at a problem, indeed. I seem to have two autoreconf
> installed: 2.65, from EZWinports, in my C:\devel\build\bin directory,
> and 2.68 in MinGW/bin.

Which directory is earlier on MSYS PATH?

In any case, I suggest to leave only one version of each auto-tool.

Re: Trunk r117046 fails on systems with older automake

[Andy Moreton]

On Wed 07 May 2014, Juanma Barranquero wrote:

> On Wed, May 7, 2014 at 5:32 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> Does pkg-config run from the cmd prompt
>
> I don't have MinGW or MSYS in the PATH, so they don't run from CMD.
> Everything I run to build Emacs runs from the MSYS sh.exe with a path
> than includes MinGW\bin and MSYS\1.0\bin, and C:\devel\emacs\build\bin
> (which has many EZWinports tools).
>
> (mdo = "c:\bin\MinGW\msys\1.0\bin\sh.exe --login -i")
>
>   C:\> mdo pkg-config --version
>   0.28
>
>> or does it show a "DLL
>> missing" dialog or some other failure?  Do you see any pkg-config
>> related error messages in config.log?
>
> No to both.
>
>> Which m4.exe do you have installed, MSYS or MinGW?
>
> MSYS.
>
>> What version(s) of  them?
>
>   C:\> mdo m4 --version
>   m4 (GNU M4) 1.4.16
>
>> What do you get if you run "autoreconf -v -v --warnings=all -fi -I m4"
>> from the MSYS Bash promt -- do you get the same output as what I sent
>> (off list)?  Any errors/warnings that could hint at the problem?
>
> It fails with
>
>   configure.ac:70: error: possibly undefined macro: AS_ECHO
>       If this token and others are legitimate, please use m4_pattern_allow.
>       See the Autoconf documentation.
>   configure.ac:1352: error: possibly undefined macro: PKG_PROG_PKG_CONFIG
>   configure.ac:1355: error: possibly undefined macro: PKG_CHECK_MODULES
>   configure.ac:1364: error: possibly undefined macro: m4_default
>   configure.ac:2294: error: possibly undefined macro: PKG_CONFIG
>   autoreconf-2.68: /mingw/bin/autoconf-2.68 failed with exit status: 1
>
>> FWIW, I don't use Autoconf 2.68, I use 2.65 on one machine and 2.69 on
>> another (the later with a newer Automake, I think).
>
> That hints at a problem, indeed. I seem to have two autoreconf
> installed: 2.65, from EZWinports, in my C:\devel\build\bin directory,
> and 2.68 in MinGW/bin.

My setup is similar to yours (separate tree for non MinGW/MSYS sourced tools).
I found that the following steps helped for me:
 - install msys-automake and msys-autoconf (in c:/MinGW/msys)
 - uninstall ezwinports automake and autoconf from devel tree
 - install pkg-config in c:/MinGW/msys/bin
 - install pkg.m4 in c:/MinGW/msys/share/aclocal
 - run "bzr clean-tree --detritus --ignored --unknown --force" to ensure
   a clean starting point. Run autogen, configure and make as normal.

HTH,

    AndyM

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 4 May 2014 21:51:32 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, Andy Moreton <andrewjmoreton@gmail.com>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Sun, May 4, 2014 at 9:39 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> 
> > Your aclocal is broken.  Not our problem.
> 
> "My aclocal" is just straight from Eli's automake-1.11.6-msys-bin.zip
> and hasn't changed for a long while. So a recent change in the trunk
> has broken my setup.

That change started using the pkg.m4 file that previously was unused
by Emacs.

The Automake distribution you find in ezwinports cannot possibly come
with all the *.m4 files in the world, it only comes with those that
are part of Automake (and a few popular additions, I think).  The rest
should come from the additional packages you install (pkg-config in
this case); when you install these, make sure all the *.m4 files you
find there end up in your MSYS's share/aclocal/ hierarchy, duplicated
from the MinGW tree if needed.  It's a small annoyance to remember
that, but (un)fortunately, if you forget, you are reminded soon enough
with error messages from Automake like the ones you saw in this case.

I will update the ezwinports distro nonetheless.

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 4 May 2014 21:28:25 +0200
> Cc: Andy Moreton <andrewjmoreton@gmail.com>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> Checking for pkg-config (need at least version 0.9.0)...
> ok
> Checking for pkg.m4...
> Can't locate Automake/Getopt.pm in @INC (@INC contains:

I think the message about Getopt.pm is bogus: the Automake package
from ezwinports does include that file.  Please verify that you do
have it.

> The version of aclocal that you are using cannot find the pkg.m4 file that
> pkg-config provides.

I think the problem is with pkg.m4, which comes with the pkg-config
package (see the message above).  My crystal ball says that you do
have that file, but in the wrong place: since your pkg-config is a
MinGW port, you have that file in share/aclocal under the MinGW root,
but not under the MSYS root.

In general, I suggest to make sure your *.m4 files are always
duplicated in both trees, because you can never know which script will
need it and where will they look for them.

Re: Trunk r117046 fails on systems with older automake

[martin rudalics]

 >> The version of aclocal that you are using cannot find the pkg.m4 file that
 >> pkg-config provides.
 >
 > I think the problem is with pkg.m4, which comes with the pkg-config
 > package (see the message above).  My crystal ball says that you do
 > have that file, but in the wrong place: since your pkg-config is a
 > MinGW port, you have that file in share/aclocal under the MinGW root,
 > but not under the MSYS root.
 >
 > In general, I suggest to make sure your *.m4 files are always
 > duplicated in both trees, because you can never know which script will
 > need it and where will they look for them.

On Windows XP I'm currently getting


c:\emacs\trunk\nt>c:/Programme/MinGW/msys/1.0/bin/bash.exe --login -i -c  "cd /c/emacs/trunk/ ; make"
c:/Programme/MinGW/msys/1.0/bin/bash.exe --login -i -c  "cd /c/emacs/trunk/ ; rm -f src/emacs-*.exe"
c:/Programme/MinGW/msys/1.0/bin/bash.exe --login -i -c  "cd /c/emacs/trunk/ ; make"
cd . && aclocal -I m4
cd . && autoconf
configure.ac:70: error: possibly undefined macro: AS_ECHO
       If this token and others are legitimate, please use m4_pattern_allow.
       See the Autoconf documentation.
configure.ac:1351: error: possibly undefined macro: PKG_PROG_PKG_CONFIG
configure.ac:1354: error: possibly undefined macro: PKG_CHECK_MODULES
configure.ac:1363: error: possibly undefined macro: m4_default
configure.ac:2293: error: possibly undefined macro: PKG_CONFIG
make: *** [configure] Error 1


What do I have to do?

Thanks, martin

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> Date: Mon, 05 May 2014 09:29:58 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: andrewjmoreton@gmail.com, emacs-devel@gnu.org
> 
>  >> The version of aclocal that you are using cannot find the pkg.m4 file that
>  >> pkg-config provides.
>  >
>  > I think the problem is with pkg.m4, which comes with the pkg-config
>  > package (see the message above).  My crystal ball says that you do
>  > have that file, but in the wrong place: since your pkg-config is a
>  > MinGW port, you have that file in share/aclocal under the MinGW root,
>  > but not under the MSYS root.
>  >
>  > In general, I suggest to make sure your *.m4 files are always
>  > duplicated in both trees, because you can never know which script will
>  > need it and where will they look for them.
> 
> On Windows XP I'm currently getting

Why do you cite my message above?  Is your problem related to what I
wrote, and if so, how?

> cd . && aclocal -I m4
> cd . && autoconf
> configure.ac:70: error: possibly undefined macro: AS_ECHO
>        If this token and others are legitimate, please use m4_pattern_allow.
>        See the Autoconf documentation.
> [...]
> 
> What do I have to do?

What did you do since the last time this worked for you?  Line 70 of
configure.ac, and several dozen lines around it, didn't change since
last August, so something else must have happened to cause this.

AS_ECHO is defined by m4sh.m4, which is part of the MSYS Autoconf
package you find on the ezwinports site.  Are you using that package?
Do you have that file in share/autoconf/m4sugar/ in your MSYS
installation?

> configure.ac:1351: error: possibly undefined macro: PKG_PROG_PKG_CONFIG
> configure.ac:1354: error: possibly undefined macro: PKG_CHECK_MODULES
> configure.ac:1363: error: possibly undefined macro: m4_default
> configure.ac:2293: error: possibly undefined macro: PKG_CONFIG

These are because of the missing pkg.m4 file, I think.  See my advice
to Juanma earlier in this thread.

Re: Trunk r117046 fails on systems with older automake

[martin rudalics]

 > Why do you cite my message above?  Is your problem related to what I
 > wrote, and if so, how?

You seem to confirm a relation below.

 >> cd . && aclocal -I m4
 >> cd . && autoconf
 >> configure.ac:70: error: possibly undefined macro: AS_ECHO
 >>         If this token and others are legitimate, please use m4_pattern_allow.
 >>         See the Autoconf documentation.
 >> [...]
 >>
 >> What do I have to do?
 >
 > What did you do since the last time this worked for you?

bzr update

 > Line 70 of
 > configure.ac, and several dozen lines around it, didn't change since
 > last August, so something else must have happened to cause this.

I supposed so.

 > AS_ECHO is defined by m4sh.m4, which is part of the MSYS Autoconf
 > package you find on the ezwinports site.  Are you using that package?
 > Do you have that file in share/autoconf/m4sugar/ in your MSYS
 > installation?

Yes.  As c:\Programme\MinGW\msys\1.0\share\autoconf\m4sugar\m4sh.m4

 >> configure.ac:1351: error: possibly undefined macro: PKG_PROG_PKG_CONFIG
 >> configure.ac:1354: error: possibly undefined macro: PKG_CHECK_MODULES
 >> configure.ac:1363: error: possibly undefined macro: m4_default
 >> configure.ac:2293: error: possibly undefined macro: PKG_CONFIG
 >
 > These are because of the missing pkg.m4 file, I think.

And that's why I'm asking for advice in this thread.

 > See my advice
 > to Juanma earlier in this thread.

Which advice?  Is there any way to work around this without installing
pkg-config?  According to http://www.mingw.org/wiki/FAQ this would mean
I'd have to install the GTK-runtime first which I don't have either.

Thanks, martin

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> Date: Mon, 05 May 2014 11:25:02 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: lekktu@gmail.com, andrewjmoreton@gmail.com, emacs-devel@gnu.org
> 
>  > Line 70 of
>  > configure.ac, and several dozen lines around it, didn't change since
>  > last August, so something else must have happened to cause this.
> 
> I supposed so.
> 
>  > AS_ECHO is defined by m4sh.m4, which is part of the MSYS Autoconf
>  > package you find on the ezwinports site.  Are you using that package?
>  > Do you have that file in share/autoconf/m4sugar/ in your MSYS
>  > installation?
> 
> Yes.  As c:\Programme\MinGW\msys\1.0\share\autoconf\m4sugar\m4sh.m4

Then I don't know why you get this error.  "It works for me" (TM).
Some Googling suggests that this might be a result of the missing
pkg-config package (see below).  If that doesn't help, maybe some
Autoconf expert could help you out.

>  >> configure.ac:1351: error: possibly undefined macro: PKG_PROG_PKG_CONFIG
>  >> configure.ac:1354: error: possibly undefined macro: PKG_CHECK_MODULES
>  >> configure.ac:1363: error: possibly undefined macro: m4_default
>  >> configure.ac:2293: error: possibly undefined macro: PKG_CONFIG
>  >
>  > These are because of the missing pkg.m4 file, I think.
> 
> And that's why I'm asking for advice in this thread.
> 
>  > See my advice
>  > to Juanma earlier in this thread.
> 
> Which advice?  Is there any way to work around this without installing
> pkg-config?

Maybe there is, but I don't recommend that: configure scripts rely on
that package more and more as the time passes.  If you didn't have
that package until now, it means you couldn't build Emacs with librsvg
and GnuTLS.

> According to http://www.mingw.org/wiki/FAQ this would mean I'd have
> to install the GTK-runtime first

That's a damn lie.  You need only Glib (and libintl+libiconv if you
don't already have them), in addition to pkg-config itself.

So, to summarize: install pkg-config and try again (starting with
running autogen.sh, I'd suggest, to countermand any problems you might
have caused by running without pkg-config).

Re: Trunk r117046 fails on systems with older automake

[martin rudalics]

 > So, to summarize: install pkg-config and try again (starting with
 > running autogen.sh, I'd suggest, to countermand any problems you might
 > have caused by running without pkg-config).

This gives me now

checking for library containing sqrt... none required
./configure: line 9198: syntax error near unexpected token `0.9.0'
./configure: line 9198: `PKG_PROG_PKG_CONFIG(0.9.0)'
make: *** [config.status] Error 2

martin

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> Date: Mon, 05 May 2014 14:29:07 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: lekktu@gmail.com, andrewjmoreton@gmail.com, emacs-devel@gnu.org
> 
>  > So, to summarize: install pkg-config and try again (starting with
>  > running autogen.sh, I'd suggest, to countermand any problems you might
>  > have caused by running without pkg-config).
> 
> This gives me now
> 
> checking for library containing sqrt... none required
> ./configure: line 9198: syntax error near unexpected token `0.9.0'
> ./configure: line 9198: `PKG_PROG_PKG_CONFIG(0.9.0)'
> make: *** [config.status] Error 2

My line 9198 in configure is empty.  What's yours?  Sounds like
PKG_PROG_PKG_CONFIG was not expanded by autoconf when it built
configure from configure.ac?

PKG_PROG_PKG_CONFIG should be defined in share/aclocal/pkg.m4.  Please
see that you have it there, and that your pkg.m4 file is intact.

Re: Trunk r117046 fails on systems with older automake

[martin rudalics]

 > My line 9198 in configure is empty.  What's yours?  Sounds like
 > PKG_PROG_PKG_CONFIG was not expanded by autoconf when it built
 > configure from configure.ac?

Apparently.

 > PKG_PROG_PKG_CONFIG should be defined in share/aclocal/pkg.m4.  Please
 > see that you have it there, and that your pkg.m4 file is intact.

It is there and contains


# PKG_PROG_PKG_CONFIG([MIN-VERSION])
# ----------------------------------
AC_DEFUN([PKG_PROG_PKG_CONFIG],
[m4_pattern_forbid([^_?PKG_[A-Z_]+$])
m4_pattern_allow([^PKG_CONFIG(_(PATH|LIBDIR|SYSROOT_DIR|ALLOW_SYSTEM_(CFLAGS|LIBS)))?$])
m4_pattern_allow([^PKG_CONFIG_(DISABLE_UNINSTALLED|TOP_BUILD_DIR|DEBUG_SPEW)$])
AC_ARG_VAR([PKG_CONFIG], [path to pkg-config utility])
AC_ARG_VAR([PKG_CONFIG_PATH], [directories to add to pkg-config's search path])
AC_ARG_VAR([PKG_CONFIG_LIBDIR], [path overriding pkg-config's built-in search path])

if test "x$ac_cv_env_PKG_CONFIG_set" != "xset"; then
	AC_PATH_TOOL([PKG_CONFIG], [pkg-config])
fi
if test -n "$PKG_CONFIG"; then
	_pkg_min_version=m4_default([$1], [0.9.0])
	AC_MSG_CHECKING([pkg-config is at least version $_pkg_min_version])
	if $PKG_CONFIG --atleast-pkgconfig-version $_pkg_min_version; then
		AC_MSG_RESULT([yes])
	else
		AC_MSG_RESULT([no])
		PKG_CONFIG=""
	fi
fi[]dnl
])# PKG_PROG_PKG_CONFIG


martin

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> Date: Mon, 05 May 2014 15:26:52 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: lekktu@gmail.com, andrewjmoreton@gmail.com, emacs-devel@gnu.org
> 
>  > My line 9198 in configure is empty.  What's yours?  Sounds like
>  > PKG_PROG_PKG_CONFIG was not expanded by autoconf when it built
>  > configure from configure.ac?
> 
> Apparently.
> 
>  > PKG_PROG_PKG_CONFIG should be defined in share/aclocal/pkg.m4.  Please
>  > see that you have it there, and that your pkg.m4 file is intact.
> 
> It is there and contains

The contents of this definition should end up in configure.  If they
don't, then something is broken in how autoconf is run.

Do you have another pkg.m4 somewhere?  Did your installation rely on
ACLOCAL_PATH being set (looks like it's no emptied when running
'aclocal').  Is your m4.exe an MSYS program or a MinGW program?  What
about automake and autoconf: are you using the packages from
ezwinports or from somewhere else?  Do you have a single MSYS tree and
a single MinGW tree with all the tools, or do you install each package
into its own directory (which might cause trouble when one package
needs to access files installed by another)?

These are just random questions.  The truth is I don't have the
slightest idea about what's wrong there, and cannot debug this over
email, sorry.

Re: Trunk r117046 fails on systems with older automake

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 4 May 2014 21:28:25 +0200
> Cc: Andy Moreton <andrewjmoreton@gmail.com>,
> 	Emacs developers <emacs-devel@gnu.org>
> 
> On Sun, May 4, 2014 at 6:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Which change requires a newer Automake?  I have 1.11, and I've just
> > reconfigured and rebuilt the latest trunk with no problems I could
> > spot.  Can you show the details of your failure?
> 
> Checking whether you have the necessary tools...
> (Read INSTALL.REPO for more details on building Emacs)
> 
> Checking for autoconf (need at least version 2.65)...
> ok
> Checking for automake (need at least version 1.11)...
> ok
> Checking for pkg-config (need at least version 0.9.0)...
> ok
> Checking for pkg.m4...
> Can't locate Automake/Getopt.pm in @INC (@INC contains:
> /usr/share/automake-1.11 /usr/lib/perl5/5.8/msys /usr/lib/perl5/5.8
> /usr/lib/perl5/site_perl/5.8/msys /usr/lib/perl5/site_pe
> rl/5.8 /usr/lib/perl5/site_perl/5.8
> /usr/lib/perl5/vendor_perl/5.8/msys /usr/lib/perl5/vendor_perl/5.8
> /usr/lib/perl5/vendor_perl/5.8 .) at /c/Devel/emacs/build/bin/aclocal
> line 98
> 4.
> BEGIN failed--compilation aborted at /c/Devel/emacs/build/bin/aclocal line 984.
> The version of aclocal that you are using cannot find the pkg.m4 file that
> pkg-config provides.  If it is installed in some unusual directory /FOO/BAR,
> set ACLOCAL_PATH='/FOO/BAR' in the environment and run this script again.

Andy, was your problem the same, or was it different?  If the latter,
could you please show your error messages?

Re: Trunk r117046 fails on systems with older automake

[Glenn Morris]

Andy Moreton wrote:

> In trunk r117046 changes were made which assume that automake 1.13 is
> present, but configure.ac still contains AM_INIT_AUTOMAKE(1.11).

Not AFAICS. Works fine for me with automake 1.11 on GNU/Linux.
That macro is documented (as a no-op) in automake 1.11.

Re: Trunk r117046 fails on systems with older automake

[Andy Moreton]

On Sun 04 May 2014, Glenn Morris wrote:

> Andy Moreton wrote:
>
>> In trunk r117046 changes were made which assume that automake 1.13 is
>> present, but configure.ac still contains AM_INIT_AUTOMAKE(1.11).
>
> Not AFAICS. Works fine for me with automake 1.11 on GNU/Linux.
> That macro is documented (as a no-op) in automake 1.11.

r117046 contains:

dnl automake 1.13 and later understand this, making -I m4 unnecessary.
AC_CONFIG_MACRO_DIR(m4)

From that comment I assumed that you had changed the required minimum
version without documenting it.

    AndyM

Re: Trunk r117046 fails on systems with older automake

[Glenn Morris]

Andy Moreton wrote:

> dnl automake 1.13 and later understand this, making -I m4 unnecessary.
> AC_CONFIG_MACRO_DIR(m4)
>
>>From that comment I assumed that you had changed the required minimum
> version without documenting it.

Well, that was an incorrect assumption.

Re: Trunk r117046 fails on systems with older automake

[Jarek Czekalski]

W dniu 2014-05-06 22:30, Glenn Morris pisze:
> Andy Moreton wrote:
>
>> dnl automake 1.13 and later understand this, making -I m4 unnecessary.
>> AC_CONFIG_MACRO_DIR(m4)
>>
>> >From that comment I assumed that you had changed the required minimum
>> version without documenting it.
> Well, that was an incorrect assumption.
>
>

Glenn,

r117046 is an example of worst possible commit message. The commit 
message should explain the reason for which the change was done. Most of 
us don't know why the change was needed. Now we now how much fuss an 
unclear commit may do.

Jarek

Re: Trunk r117046 fails on systems with older automake

[Glenn Morris]

Jarek Czekalski wrote:

> r117046 is an example of worst possible commit message. The commit
> message should explain the reason for which the change was done. Most
> of us don't know why the change was needed. Now we now how much fuss
> an unclear commit may do.

Stop lecturing me.

Re: Trunk r117046 fails on systems with older automake

[Jarek Czekalski]

W dniu 2014-05-07 08:42, Glenn Morris pisze:
> Jarek Czekalski wrote:
>
>> r117046 is an example of worst possible commit message. The commit
>> message should explain the reason for which the change was done. Most
>> of us don't know why the change was needed. Now we now how much fuss
>> an unclear commit may do.
> Stop lecturing me.
>
>

Why?