[PATCH 1/1] intl/plural.c: improve reproducibility

[Bystricky, Juro]

> -----Original Message-----
> From: Rical Jasan [mailto:ricaljasan@pacific.net]
> Sent: Wednesday, November 15, 2017 12:07 AM
> To: Bystricky, Juro <juro.bystricky@intel.com>; libc-alpha@sourceware.org
> Cc: joseph@codesourcery.com; ldv@sourceware.org; jurobystricky@hotmail.com
> Subject: Re: [PATCH 1/1] intl/plural.c: improve reproducibility
> 
> On 11/14/2017 01:51 PM, Juro Bystricky wrote:
> > This patch fixes this by insisting on having a proper "bison" installed
> 
> Normally, requiring unnecessary dependencies raises a red flag for me,
> but I don't think I've ever built glibc on a system that didn't have bison.
> 
> Some of the distro maintainers may have a better sense of how ubiquitous
> Bison 2.7 or greater is, but checking around a few systems I have, there
> are some with 2.4.1.  Arguably, those are getting more and more
> difficult to build anything modern on anyway, and I usually build
> essential tools from source when I need to do that kind of work.
> 

"configure" will report an error if a proper version Bison is not found.
But there may be container builds with no Bison. 

> I've personally never noticed a problem, but the desire to have
> consistent binaries in automated builds has merit, in my opinion.
> However, I noticed according to the bug report in [1], your fix was to
> never regenerate plural.c (which would be the opposite approach).  Here,

in order to make sure the "make" rule fires deterministically,
one of the files needed to be explicitly touched. I will change [1]
to touch plural.y.

> you're proposing to always generate it at build time, which should be
> consistent with the bison you routinely use, but wouldn't never
> regenerating plural.c be more universally consistent across all glibc
> builds?  (Updating it in the repo when plural.y changes, of course.)

That was my first idea as well, but see [2]

> 
> I'm on the fence about tracking generated files in the first place
> (you're not the only one who's been advised they edited the wrong file
> :), and I don't see a real problem with your patch
> 

yes, not too obvious what is required and how to generate "configure" in particular.
Running autoconf on configure.ac creates some additional command line arguments,
which I had to manually edit out. Seems like everybody that modified configure.ac
has been doing this silently as well. 

> but I think adding a
> new hard dependency deserves discussion, so I wanted to kick it off.

I agree, discussion is always good. However, meanwhile I sent in a V2 version
of the patch. It ended up being top-posted, so any discussion should probably 
continue there..


> Rical
> 
> [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=12291

[2] https://sourceware.org/bugzilla/show_bug.cgi?id=22432