gmane.comp.sysutils.autoconf.patches

Re: [PATCH] general: deprecate 'configure.in' as autoconf input

Stefano Lattarini — 2012-05-22T22:13:53

Thanks Eric nad Paul for your feedback.  I've pushed the patch to master.

Regards,
  Stefano

Re: [PATCH] general: deprecate 'configure.in' as autoconf input

Eric Blake — 2012-05-22T16:29:57

Agreed.  Let's go for it.  We still need to figure out if it is worth
sharing the .pm files in gnulib as a common upstream to both autoconf
and automake, but I haven't had time to look into that yet.

Re: [PATCH] general: deprecate 'configure.in' as autoconf input

Paul Eggert — 2012-05-22T16:24:25

This change is fine with me.  The only package I know that's
still using configure.in is Emacs, and I can rename that.

Re: [PATCH] general: deprecate 'configure.in' as autoconf input

Stefano Lattarini — 2012-05-22T10:29:51

Ping?

Regards,
  Stefano

[PATCH] general: deprecate 'configure.in' as autoconf input

Stefano Lattarini — 2012-05-19T08:25:16

It has been years since that has been deprecated in the documentation,
in favour of 'configure.ac':

  Previous versions of Autoconf promoted the name configure.in, which
  is somewhat ambiguous (the tool needed to process this file is not
  described by its extension), and introduces a slight confusion with
  config.h.in and so on (for which '.in' means "to be processed by
  configure"). Using configure.ac is now preferred.

It's now time to start giving runtime warning about the use of
'configure.in', so that support for it can be removed in future
versions of autoconf/automake.

* lib/Autom4te/Configure_ac.pm: Issue a warning in the 'obsolete'
category if 'configure.in' is detected.  Since this module is synced
from Automake, this change is to be backported there (and will be
soon).
* doc/autoconf.texi: Update.
* tests/tools.at: Adjust to avoid spurious failures.

Signed-off-by: Stefano Lattarini <stefano.lattarini< at >gmail.com>
---

 OK to apply?  I plan to backport the change done to Configure_ac.pm
 to th

Re: [PATCH] Improve cross-compilation guesses for glibc system hosts.

Eric Blake — 2012-05-03T16:55:50


Thanks; pushed.

[PATCH] doc: fix another bad < at >xref

Eric Blake — 2012-05-03T15:29:30

Obviously, I didn't fully test commit f35498d.

* doc/autoconf.texi (Limitations of Builtins): Add a comma.

Signed-off-by: Eric Blake <eblake< at >redhat.com>
---
 doc/autoconf.texi |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 34ca213..393e38f 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
< at >< at > -17874,7 +17874,7 < at >< at > Limitations of Builtins
 < at >samp{-}. With Solaris < at >command{ksh}, it is possible to use < at >code{print
 -r --} for this role instead.

-< at >xref{echo, , Limitations of Shell Builtins} for a discussion of
+< at >xref{echo, , Limitations of Shell Builtins}, for a discussion of
 portable alternatives to both < at >command{printf} and < at >command{echo}.

[PATCH] Improve cross-compilation guesses for glibc system hosts.

Bruno Haible — 2012-05-02T21:02:49

Hi,

Paul and Eric suggested that improving the cross-compilation guesses
for targets that are glibc systems would be welcome here [1][2], so here
is a proposed patch.

This patch modifies the cross-compilation behaviour of
  AC_FUNC_CHOWN
  AC_FUNC_GETGROUPS
  AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK
  AC_FUNC_MALLOC
  AC_FUNC_MMAP
  AC_FUNC_REALLOC
  AC_FUNC_STRCOLL
so that when the target is a glibc system (or, in case of AC_FUNC_MALLOC
and AC_FUNC_REALLOC, any known "good" Unix system), the guess is
"yes it works" rather than "guessing no".

This is important because some of these macros are used in Gnulib, and
in case of "guessing no" Gnulib provides extra workaround code, and
  1) Generally, when targetting embedded systems, code size should be
     minimized,
  2) In [3], unnecessary workaround code will look like a Glibc bug.

This patch also changes the configure output to "guessing yes" or
"guessing no" in a case where the ac_cv_* variable is undocumented.

[1] http://lists.gnu.org/archive/html/bug-gn

[PATCH] maint: drop bz2 tarball

Eric Blake — 2012-04-25T02:46:27

At 2.68b, I asked whether anyone would miss .gz and .bz2 formats.
Consensus was overwhelming that .gz still holds a place in people's
hearts, in spite of .xz compressing to smaller files, but no one
was able to make a convincing argument for .bz2.

* configure.ac (AM_INIT_AUTOMAKE): Drop bzip2; xz wins hands down.

Signed-off-by: Eric Blake <eblake< at >redhat.com>
---

See https://lists.gnu.org/archive/html/autoconf/2012-03/msg00001.html
for the long thread of discussion.

 configure.ac |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 280cc0e..696e513 100644
--- a/configure.ac
+++ b/configure.ac
< at >< at > -26,8 +26,7 < at >< at > AC_CONFIG_SRCDIR([lib/autoconf/autoconf.m4])

 AC_CONFIG_AUX_DIR([build-aux])

-AM_INIT_AUTOMAKE([1.11 dist-bzip2 dist-xz
-readme-alpha no-texinfo.tex std-options])
+AM_INIT_AUTOMAKE([1.11 dist-xz readme-alpha no-texinfo.tex std-options])

 AB_INIT

[PATCH] doc: fix bad < at >xref uses

Eric Blake — 2012-04-25T02:13:47

Upstream gnulib maint.mk improvements caught a few issues we
should fix, as well as a few issues in files we copy from
other sources that we will just ignore here.

* doc/autoconf.texi (Generic Programs, Special Shell Variables)
(Limitations of Builtins): Use references correctly.
* cfg.mk
(exclude_file_name_regexp--sc_prohibit_undesirable_word_seq)
(exclude_file_name_regexp--sc_useless_cpp_parens): Add exemptions.
---
 cfg.mk            |    7 ++++---
 doc/autoconf.texi |    8 ++++----
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/cfg.mk b/cfg.mk
index 3febab0..e79ff55 100644
--- a/cfg.mk
+++ b/cfg.mk
< at >< at > -129,12 +129,13 < at >< at > update-copyright-env = \
 # Prevent incorrect NEWS edits.
 old_NEWS_hash = 54ad39275441a2a3fcbe6182da4f84fb

-exclude_file_name_regexp--sc_prohibit_undesirable_word_seq = ^maint\.mk$$
+exclude_file_name_regexp--sc_prohibit_undesirable_word_seq = \
+  ^(maint\.mk|build-aux/texinfo\.tex)$$
 exclude_file_name_regexp--sc_prohibit_test_minus_ao = \
   ^(maint\.mk|doc/autoconf

[PATCH] maint: resync files from upstream

Eric Blake — 2012-04-24T23:38:03

The files in lib/Autom4te/ are intentionally not synced at this
point, since this recent Automake patch:
https://lists.gnu.org/archive/html/automake-patches/2012-03/msg00111.html

was buggy regarding '-' as stdout, and also exposes some latent
bugs in autoconf where we use raw 'open' instead of XFile::open.

* build-aux/announce-gen: Resync via 'make fetch'.
* build-aux/config.sub: Likewise.
* build-aux/git-version-gen: Likewise.
* build-aux/gnupload: Likewise.
* build-aux/move-if-change: Likewise.
* build-aux/texinfo.tex: Likewise.
* doc/standards.texi: Likewise.
* maint.mk: Likewise.
---

Ultimately, I want to fix the bugs in XFile.pm, and in autoconf's
improper use of raw 'open', but that can wait until after autoconf
2.69 and automake 1.12, as it may prove a bit disruptive.

 build-aux/announce-gen    |    5 +-
 build-aux/config.sub      |    8 +++-
 build-aux/git-version-gen |    5 +-
 build-aux/gnupload        |    2 +-
 build-aux/move-if-change  |    2 +-
 build-aux/texinfo.tex     |  101 ++++++++++++

Re: [PATCH] remove warning for --host without --build

Bruno Haible — 2012-04-24T21:52:41

Thanks Eric for applying the patches.

Eric Blake wrote to Peter Rosin:

Such a knob already exists and is documented since today: it is to
pass both --build and --host with different values.

Bruno

Re: [PATCH] remove warning for --host without --build

Eric Blake — 2012-04-24T21:19:33

This is the clincher - it's only a warning, and by now, people have
migrated to saner usage patterns with the modern semantics of --build
and --host.  I will go ahead and apply this.

Re: [PATCH] remove warning for --host without --build

Eric Blake — 2012-04-24T21:13:49

It _IS_ a cross-compile, but in the special subset of cross-compiles
that also happen to be executable from the host.  And this opens up all
sorts of problems where running the executable in a non-native
environment gives outright confusing results (such as thinking that
mingw supports symlinks).  But that generally boils down to the bug of
the person invoking configure lying about their environment, and not
something intrinsically bad with our cross-compilation hueristics.  And
the set of platforms where a cross-compilation allows native execution
is small enough that we already tend to recognize such bug reports
(you're compiling for mingw but using cygwin? did you use the right
arguments?), whether or not the user paid attention to the warning from
configure.


A cross-compilation environment where wine lets you run mingw binaries
is slightly different from a cross-compilation environment where
everything has to be guessed; both environments are interesting, to
different sets of users.  Maybe you are rig

Re: [PATCH] remove warning for --host without --build

Eric Blake — 2012-04-24T21:01:30


This patch looks fine, although it didn't apply very easily through 'git
am'.

Re: [PATCH] remove warning for --host without --build

Bruno Haible — 2012-04-23T20:10:57

Yes, and documentation can help people to understand this.


More precisely, I think that activating cross-compilation mode when
it is not necessary leads to suboptimal guesses from 'configure'.
But it is good that there is a mechanism to force cross-compilation
mode, because some compiler guys apparently want to have this.


Would it satisfy you to add some more documentation to the
'cross_compiling' variable?


I object against this: It would deteriorate the results of bi-arch builds
(e.g. x86 on x86_64) and of mingw builds when run from Cygwin or Linux/Wine.


The fix for these people is easy: They can use
   test "$host_alias" != "$build_alias"

Bruno

Re: [PATCH] remove warning for --host without --build

Bruno Haible — 2012-04-23T19:43:04

Hi Paul,


Ouch. There are now two wrong/inconsistent pieces of doc here:

1) The documentation of AC_RUN_IFELSE does not mention the cross-compilation
   mode. It says

     If the compiler being used does not produce executables that run
     on the system where `configure' is being run, then the test
     program is not run.

   which is factually wrong.

2) The second paragraph you showed says that specifying --host enables
   the cross-compilation mode. Either the cross-compilation mode influences
   AC_RUN_IFELSE - then this statement is wrong. Or it has no influence on
   AC_RUN_IFELSE - then what are its effect, what is this doc all about?

Let's go back to the sample provided by Peter Rosin:

===================== configure.ac ================
AC_INIT([cross-test], [0.1])
AC_PROG_CC
AC_RUN_IFELSE(
  [AC_LANG_PROGRAM([[]],[[]])],
  [echo executable],
  [echo not executable],
  [echo not attempted to execute])
AC_OUTPUT
===================================================

On Cygwin 1.5:

$ ./configure

Re: [PATCH] remove warning for --host without --build

Peter Rosin — 2012-04-23T19:38:09

And I have the nagging suspicion that one of the meanings spring from
the fact that people simply do not want to do exotic stuff such as cross
compiling because of rumors that it is complex.  They rather look upon
what they are doing as something that everybody else is also doing, but
with a little twist.

No no no no. I'm not cross compiling. NO! No no. La la la...


Perhaps.  I've made my case and will try to not extend this thread further.

Cheers,
Peter

Re: [PATCH] remove warning for --host without --build

Peter Rosin — 2012-04-23T19:10:23

Currently "./configure --host=foo --build=`./config.guess`" is
different from "./configure --host=foo" on a build system that
can execute host code (such as when doing Cygwin->MinGW or
Linux-x86_64->Linux-x86 crosses) in that the former enters
cross-compile mode, but the latter doesn't.

It is clearly confusing that you get different behavior by
explicitly specifying a default value.

Bruno thinks it is bad to enter cross-compile mode when the build
system can execute host code and wants to zap the warning that
keeps nagging his use case (i.e. not specifying --build).

I think it is bad that the variable 'cross_compiling' is set
to the wrong thing and would rather get rid of the heuristic
that sets it to "no" just because the build system happens to be
able to run host code.  People have been known to use the outcome
of that test as an argument that they are not cross-compiling when
in fact they are.  But I also recognize that Bruno have a valid
use case, but think executing the tests in cross-compile mode

Re: [PATCH] remove warning for --host without --build

Bruno Haible — 2012-04-23T19:02:10

I don't want to discuss words. The term "cross compile" was coined at
a time when every machine had only 1 format of executables that it could
execute. Now there are two possible meanings of the term.


There's nothing fragile about it. Autoconf detects whether it can run
binaries produced by $CC or not. It's in line with Autoconf's design to
determine attributes about the build environment, so that the user does
not have to provide this information explicitly.

Bruno

Re: [PATCH] remove warning for --host without --build

Paul Eggert — 2012-04-23T17:32:37

Thanks, I pushed the following slightly-different
(and I hope clearer) patch.  I don't understand
the disagreement about what --host and --build
should do (I try not to do cross-builds myself...)
but at least this helps document what autoconf
currently does, and it can be changed if the behavior
needs to be changed.

From 71d2c125cb3ad167a59776a3bab0e95169805af0 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert< at >cs.ucla.edu>
Date: Mon, 23 Apr 2012 10:30:05 -0700
Subject: [PATCH] doc: document --build and cross-compilation better

* doc/autoconf.texi (Specifying Target Triplets): Mention that
specifying a build-type that differs from host-type enables
cross-compilation.  Problem reported by Bruno Haible in:
http://lists.gnu.org/archive/html/autoconf-patches/2012-04/msg00009.html
---
 doc/autoconf.texi |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 2ae8bb9..b1295eb 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
< at >< at > -21747,10 +2174