This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
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])])
;-P
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.