This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

gcc-tools versions of autotools [Fwd: Moving to Autoconf 2.64, Automake 1.11]


(Mostly for Dave Korn, but other opinions solicited):

How do you want me to handle updating gcc-tools-autoconf and
gcc-tools-automake?  My preference would be to /not/ update them at all;
at least, not for a while.  Reasons:

1) The current and soon-to-be-released gcc's, based on gcc-3.4.5 and
gcc-4.3.x, both still require autoconf-2.59 and automake-1.9.6
[actually, I'm not sure about that; gcc-3.x might still be stuck in
ac-2.13 land].

2) The only reason we needed separate versions of these autotools rather
than using the cygwin standard ones was because the cygwin standard
versions have been modified from the pristine upstream editions.  This
means that patches including regenned files would be unacceptable
upstream.  However, the cygwin standard version of automake-1.11 has no
substantantive patches -- only automake.texi.  Ditto autoconf-2.63 --
only autoconf.texi and autoconf.el.

I have no doubt that autoconf-2.64 will also need no cygwin-specific
modifications.

So, as soon as I spin the "regular" cygwin autoconf-2.64 package, then
our "standard" auto* installations will satisfy gcc's needs; all you'd
need to do is /stop/ setting PATH to prepend /opt/gcc-tools/bin.

...until automake-1.11.1 or autoconf-2.65 is released.  Then we get to
worry about it more. I've a few ideas about that, but for later...unless
you want to handle the transition /now/ for gcc-tools-*.

Side question: has anybody checked to see if src/winsup can handle
autoconf-2.64 and automake-1.11?

--
Chuck
--- Begin Message ---
Hello everyone,

I will reply to this message with a number of patches that contain the
heart of the switch to newer autotools.  They apply in the order posted,
and each successive version is expected to work, or at least only break
minor bits such as provoking an automake warning about duplicate
install-pdf, but my plan is to get them all approved and then apply them
in short succession.  (Splitting them by topic is really helpful to
maintain sanity, and be able to distinguish generated from manual
changes.) For committing the series, would it be ok to then ask for a
couple of hours in which no changes to the build system are made?


- Update automake-provided helper scripts in the toplevel,
- LIBTOOLFLAGS, and *_LINK fixes for Automake 1.11 (GCC only),
- some minor fixes in sim, gold, gdb (src only)
- Bump Autoconf version to 2.64 in override.m4, and regenerate the
  world with 2.64 and Automake 1.11,
- remove {all,install}-{html,pdf} and {dataroot,doc,pdf,html}dir stuff
  not needed any more, update documentation bits throughout the tree.

Apart from that, I would need somebody to update the autotools tarballs
at ftp://sources.redhat.com/pub/binutils for me, at the time I am
committing the above.  The upstream tarballs are available here:
  ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.64.tar.gz
  ftp://ftp.gnu.org/gnu/automake/automake-1.11.tar.gz


I have done a bunch of testing of the resulting trees, mostly native
bootstraps+regtests however (no regressions).  I think I have addressed
all issues that cropped up and that have been documented before on this
list.  Notably, however, I have not done a --with-build-sysroot test; I
would like to ask someone else to do this for me.  I do have good reason
to believe that the issue reportd in
<http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00912.html> is fixed in
my patch series, though: the very likely reason for the above was that
the *_LDFLAGS/*_LINK semantic change was not addressed.

The texinfo changes have been tested with 'make info pdf html'.

To make it easy for whoever volunteers for the --with-build-sysroot
test, I would like to ask for this to be done after I commit the patch
set.  OK?

Note that I do expect one or two more things that could break some
specific build setups; I don't think it is feasible to test them all in
advance, but I will try to look at them in a short order then.

This patch series can be extended with two more helpful changes that
are not time-critical:

- bump all the AC_PREREQ's to 2.64, add 1.11 to AUTOMAKE_OPTIONS or
  AM_INIT_AUTOMAKE calls as requirement, to avoid accidental use of old
  tools.  The config/override.m4 bit ought to prevent the error for
  Autoconf already, unless other weird issues come into play, too, such
  as also inadvertently dropping some aclocal -I ../config options or
  so.  (My thinking here was that, as some parts of the tree are shared
  with external projects, they don't need to upgrade their autotools
  usage right at the same time.)

- fix the (new with Autoconf 2.64) warnings from configure about unknown
  --enable/--with switches.  I would appreciate some input on whether
  this functionality should just be turned off with
  AC_DISABLE_OPTION_CHECKING, or we should add some logic to the
  toplevel configure script to be more intelligent about it.


Thanks for all the review work done so far!
Ralf



--- End Message ---
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]