X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
	bh=W1eyYfhXh4wWhR1mpv8d3Zbq96nBKYUqtdEWrZ85I/g=;
	b=FWti8BMLIXPu6Ir5t8iuAX8RfJwS2Q2Jjn3nCM2z0SFtHX/E+RFpCMWOsF6sA9l4iS
	xk0vl+HEkmVr4mI8dVRuvVBoFHZUUp6oYGCTgRu1sEZxCxNDfW388Lw9/8XwLVBZ14Jl
	zMTY5FmNlgAEGyg/4f5b+JgAQBqQNucBAygj1vtn73gNASq5pNdIM9ZwwqtCV+7C6OAw
	HhvZAjqtV7Uwh9wesVjDuut7a8Qjw1LsBJD42/o7Pmgb63i4MLI2RODP6dkECY+0Hr/1
	tf8iE5Y9MX/cZVL3sBPom5+tNck2CnBJw7rjHl1EWQNday/2/ARdslunh4h9KH1HrSh2
	1avw==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=W1eyYfhXh4wWhR1mpv8d3Zbq96nBKYUqtdEWrZ85I/g=;
	b=GrU4eZqQaRSPgIhN8IV6P4TNoK2608tGAvrZd0BpXu4edTwijaAHrIfU7J3mLlyqxw
	tD4qJvh0WsOGnrlOuB22b/uKnf52npv5GZlKa+8kgws+Gy07eB0qhWkTwS+4oF4DZf4v
	PN4SGHylbSpqUk7Eq5PIHCbhcyeJj+Hbhl1kdPhJOr7y8imoIEanV6zZZv7e4eDfk6is
	1Rdlv8OkydYIMawqn1Du/0wdHLbALP/x7lLUP8jvNzoFa1Pa/qAP/YMzDLinFKfFNJHA
	g4O2cLCHNKQ8S4TmRrSiy5SdTTvM8Tubcyjiersi5NyW61hRcncKJzALfE3saOJY19c9
	3ItA==
X-Gm-Message-State:	AIkVDXIk5VFtd+DB/jzUCTSybg2AbW5xmCwqrbYUG+UFbqqo/DSTD9N0UCbcayMJvzHzTvqBTBYPeDRCGY+uog==
X-Received:	by 10.28.173.4 with SMTP id w4mr1543533wme.70.1483817921550; Sat,
	07 Jan 2017 11:38:41 -0800 (PST)
MIME-Version:	1.0
In-Reply-To:	<1e171791-3d29-b8f1-0452-36ecab1bf222@mcmahill.net>
References:	<CAJZxidDOQ3UdZ7AKxUFeVDrfAj8Xd7-0WyewE_hDSgq13ypPbA AT mail DOT gmail DOT com>
	<1e171791-3d29-b8f1-0452-36ecab1bf222 AT mcmahill DOT net>
From:	"Chad Parker (parker DOT charles AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Date:	Sat, 7 Jan 2017 14:38:40 -0500
Message-ID:	<CAJZxidDKO6PGmp-eNCqOaqycYC2QPV5fW10pUjdHxru4GYtxnA@mail.gmail.com>
Subject:	Re: [geda-user] [pcb] make distcheck, Bison 3, intl, and with-included-gettext
To:	geda-user AT delorie DOT com
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

--001a1144214e20225405458648f4
Content-Type: text/plain; charset=UTF-8

I've been looking at this a little more.

This is what happens when I build in a Debian VM:
The first time that autogen.sh is run, autopoint copies everything into the
intl/ directory.
The second time that autogen.sh is run, autopoint only copies intl/plural.c
and po/Makefile.in.in.
So, since plural.c is newer than plural.y, make wont regenerate plural.c
from plural.y and the new plural.c is used. The two plural.c files aren't
the same, they're generated from two different version of Bison. From the
diff:

-/* A Bison parser, made by GNU Bison 2.7. */ (build by make from plural.y)
+/* A Bison parser, made from plural.y
+ by GNU bison 1.35. */ (2nd invocation overwrites built version with this,
this version works)

I'm not sure where the second plural.c file is coming from (or the first
for that matter), I can't find it anywhere on my system. Is it dynamically
generated? Bison on the Debian VM is version 3.0.2.

The version of gettext that gets included in the distribution is determined
by the AM_GNU_GETTEXT_VERSION macro in configure.ac. This is read by
autopoint when autogen.sh is executed, and the files for whatever the
requested version of gettext is are copied into intl/.

Presently, we're calling out version 0.14 in configure.ac. I tried bumping
gettext to version 0.19.3 (what's installed on the VM) and make distcheck
succeeds the first time. This version was released in 2014-10, so it's a
little over two years old. I tried with version 0.18, and that also fails
the same way as with version 0.14.

So, another solution is to bump the version of gettext.

Any thoughts on this? I know we shouldn't arbitrarily bump external version
requirements, and I haven't heard any bug reports on the
internationalization front, so, we would only be doing this so that make
distcheck builds cleanly, so maybe we should just not worry about it.

The --with-included-gettext option is used to configure in the make
distcheck target. So, I imagine that most people are not specifying this
option and using their own external version when they build, which is
probably newer anyway (but I could be wrong). Does anyone know why automake
includes this option in the distcheck target?

--Chad

On Mon, Jan 2, 2017 at 11:16 PM, Dan McMahill (dan AT mcmahill DOT net) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:

> On 1/1/2017 5:26 PM, Chad Parker (parker DOT charles AT gmail DOT com) [via
> geda-user AT delorie DOT com] wrote:
>
>> All-
>>
>> While working on preparing a release, I've run into a bug that I could
>> use some advice on.
>>
>> Make distcheck fails in the intl/ directory while trying to build
>> plural.o (based on plural.c from plural.y). I don't quite understand
>> what's behind the error, but apparently its a bug related to Bison 3.
>> I've posted a few references at the end of this bug report that
>> references the errors:
>> https://bugs.launchpad.net/pcb/+bug/1496105
>> although, the solution of running the sequence twice doesn't appear to
>> work for me.
>>
>> When executing the make distcheck, configure is executed with the
>> --with-included-gettext option. Removing this option allows the
>> distcheck to succeed. Does anyone know if there's a particular reason
>> for this? Removing this option is the easiest solution I think, if it
>> doesn't cause some other problems. There does appear to be an alternate
>> solution, but it is more complicated.
>>
>
> That is one of the details of gettext that I don't clearly understand.
>
> When running the 'make distcheck' twice and getting it to work, it would
> be interesting to see the difference between the source tree before and
> after the first one.
>
> If we have some dependencies on particular bison behaviors or versions, or
> also requiring flex instead of lex, we should capture that in the
> documentation and some configure checks.
>
> I'm curious if you had any other issues.  I'm failing 'make distcheck'
> because of some broken stuff in src/Makefile.am.  I'll start a different
> thread for that.
>
> -Dan
>
>

--001a1144214e20225405458648f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail-m_-2932847333051112936gmail-boardComme=
ntBody" id=3D"gmail-m_-2932847333051112936gmail-yui_3_10_3_1_1483748444226_=
2107">I&#39;ve been looking at this a little more.<div class=3D"gmail-m_-29=
32847333051112936gmail-comment-text" id=3D"gmail-m_-2932847333051112936gmai=
l-yui_3_10_3_1_1483748444226_2106">
<p>This is what happens when I build in a Debian VM:<br>
The first time that autogen.sh is run, autopoint copies everything into the=
 intl/ directory.<br>
The second time that autogen.sh is run, autopoint only copies intl/plural.c=
 and po/<a href=3D"http://Makefile.in.in">Makefile.in.in</a>.<br>
So, since plural.c is newer than plural.y, make wont regenerate plural.c
 from plural.y and the new plural.c is used. The two plural.c files=20
aren&#39;t the same, they&#39;re generated from two different version of Bi=
son.=20
From the diff:</p>
<p>-/* A Bison parser, made by GNU Bison 2.7.  */ (build by make from plura=
l.y)<br>
+/* A Bison parser, made from plural.y <br>
+   by GNU bison 1.35.  */ (2nd invocation overwrites built version with th=
is, this version works)</p>
<p>I&#39;m not sure where the second plural.c file is coming from (or the f=
irst for that matter), I can&#39;t find it anywhere on my system. Is it dyn=
amically generated? Bison on the Debian VM is version 3.0.2. <br></p><p>The=
 version of gettext that gets included in the distribution is determined by=
 the AM_GNU_GETTEXT_VERSION macro in <a href=3D"http://configure.ac">config=
ure.ac</a>. This is read by autopoint when autogen.sh is executed, and the =
files for whatever the requested version of gettext is are copied into intl=
/. <br></p><p>Presently, we&#39;re calling out version 0.14 in <a href=3D"h=
ttp://configure.ac">configure.ac</a>. I tried bumping gettext to version 0.=
19.3 (what&#39;s installed on the VM) and make distcheck succeeds the first=
 time. This version was released in 2014-10, so it&#39;s a little over two =
years old. I tried with version 0.18, and that also fails the same way as w=
ith version 0.14.</p><p>So, another solution is to bump the version of gett=
ext.<br></p><p>Any thoughts on this? I know we shouldn&#39;t arbitrarily bu=
mp external version requirements, and I haven&#39;t heard any bug reports o=
n the internationalization front, so, we would only be doing this so that m=
ake distcheck builds cleanly, so maybe we should just not worry about it. <=
br></p><p>The --with-included-gettext option is used to configure in the ma=
ke distcheck target. So, I imagine that most people are not specifying this=
 option and using their own external version when they build, which is prob=
ably newer anyway (but I could be wrong). Does anyone know why automake inc=
ludes this option in the distcheck target?</p><p>--Chad<br></p></div>
 =20
 =20
 =20


  </div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On =
Mon, Jan 2, 2017 at 11:16 PM, Dan McMahill (<a href=3D"mailto:dan AT mcmahill.=
net">dan AT mcmahill DOT net</a>) [via <a href=3D"mailto:geda-user AT delorie DOT com">ge=
da-user AT delorie DOT com</a>] <span dir=3D"ltr">&lt;<a href=3D"mailto:geda-user@=
delorie.com" target=3D"_blank">geda-user AT delorie DOT com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><span class=3D"">On 1/1/2017 5:26 PM, Cha=
d Parker (<a href=3D"mailto:parker DOT charles AT gmail DOT com" target=3D"_blank">par=
ker DOT charles AT gmail DOT com</a>) [via <a href=3D"mailto:geda-user AT delorie DOT com" ta=
rget=3D"_blank">geda-user AT delorie DOT com</a>] wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
All-<br>
<br>
While working on preparing a release, I&#39;ve run into a bug that I could<=
br>
use some advice on.<br>
<br>
Make distcheck fails in the intl/ directory while trying to build<br>
plural.o (based on plural.c from plural.y). I don&#39;t quite understand<br=
>
what&#39;s behind the error, but apparently its a bug related to Bison 3.<b=
r>
I&#39;ve posted a few references at the end of this bug report that<br>
references the errors:<br>
<a href=3D"https://bugs.launchpad.net/pcb/+bug/1496105" rel=3D"noreferrer" =
target=3D"_blank">https://bugs.launchpad.net/pcb<wbr>/+bug/1496105</a><br>
although, the solution of running the sequence twice doesn&#39;t appear to<=
br>
work for me.<br>
<br>
When executing the make distcheck, configure is executed with the<br>
--with-included-gettext option. Removing this option allows the<br>
distcheck to succeed. Does anyone know if there&#39;s a particular reason<b=
r>
for this? Removing this option is the easiest solution I think, if it<br>
doesn&#39;t cause some other problems. There does appear to be an alternate=
<br>
solution, but it is more complicated.<br>
</blockquote>
<br></span>
That is one of the details of gettext that I don&#39;t clearly understand.<=
br>
<br>
When running the &#39;make distcheck&#39; twice and getting it to work, it =
would be interesting to see the difference between the source tree before a=
nd after the first one.<br>
<br>
If we have some dependencies on particular bison behaviors or versions, or =
also requiring flex instead of lex, we should capture that in the documenta=
tion and some configure checks.<br>
<br>
I&#39;m curious if you had any other issues.=C2=A0 I&#39;m failing &#39;mak=
e distcheck&#39; because of some broken stuff in src/Makefile.am.=C2=A0 I&#=
39;ll start a different thread for that.<span class=3D"HOEnZb"><font color=
=3D"#888888"><br>
<br>
-Dan<br>
<br>
</font></span></blockquote></div><br></div>

--001a1144214e20225405458648f4--

- Raw text -