This is the mail archive of the mailing list for the newlib 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]

Re: GIT source build failure: wcwidth.c::_wcwidth misses __locale_cjk_lang()

Am 24.08.2016 um 17:21 schrieb Eric Blake:
On 08/22/2016 04:23 PM, Hans-Bernhard Bröker wrote:

Well, FWIW, the attached lift-autconf-version-restriction.diff bluntly
removes that restriction.  I won't guarante the absence of any adverse
effect, thoughe ;-)

The strongest argument for insisting on an EXACT version is that you
want the generated code checked into git, and for that code to not
undergo a lot of churn if anyone regenerates it under a different
autotool version.  Once you have generated files checked in, then
developers that don't have the right autotools can get by with the
checked in output from the tools.

Fair enough.  I took the liberty of counting things in current newlib git:

      2 # Generated by GNU Autoconf 2.66.
      2 configured by $0, generated by GNU Autoconf 2.66,
      3 # Generated by GNU Autoconf 2.69.
      4 # Generated by GNU Autoconf 2.64.
      4 configured by $0, generated by GNU Autoconf 2.64,
      4 generated by GNU Autoconf 2.66.  Invocation command line was
      7 # Generated by GNU Autoconf 2.68.
      8 generated by GNU Autoconf 2.64.  Invocation command line was
     10 configured by $0, generated by GNU Autoconf 2.69,
     20 generated by GNU Autoconf 2.69.  Invocation command line was
    102 # Generated by GNU Autoconf 2.68 for newlib 2.4.0.
    102 [m4_warning([this file was generated for autoconf 2.68.
    102 m4_if(m4_defn([AC_AUTOCONF_VERSION]), [2.68],,
    112 configured by $0, generated by GNU Autoconf 2.68,
    224 generated by GNU Autoconf 2.68.  Invocation command line was

How come that the vast majority of the autoconf-generated files currently show a version 2.68, instead of the one the restriction wants to enforce:

      1   [m4_define([_GCC_AUTOCONF_VERSION], [2.64])])


As long as we rely on --cygnus, we rely on an exact version being
checked in.  But if our goal is to get rid of --cygnus, it makes more
sense to DROP the generated files from git, and to merely require that
developers have new-enough tools installed locally,

Putting generated files into version control only really makes sense if the tools needed to generate them cannot really be expected to be present in every would-be user's tool box.

And frankly it would be very strange indeed for anyone to have a version of autoconf old enough to disqualify. The version the restriction currently wants (but fails) to enforce is 2.64, from 7 years ago, and there hasn't been a new release since 2.69, 4 years ago.

So I would favor a move towards dropping the generated files altogether
from git (they would still be present in tarballs created by 'make
dist', of course),

I would agree, but then again, I'm a newbie to this source tree.

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