On 9/28/14, 4:33 PM, Mark Goldfinch wrote:
> On 29 September 2014 00:42, Christian Weisgerber wrote:
>
>> They also have a dependency on the bison port, because parse.y does
>> not build correctly with FreeBSD's yacc(1). You end up with a bash
>> that has broken $(...) parsing. Same issue on Op
On 9/28/14, 4:01 AM, Mark Goldfinch wrote:
> Greetings,
>
> On 28 Sep 2014 19:41, "John E. Malmberg" wrote:
>>
>> On 9/27/2014 6:49 PM, Mark Goldfinch wrote:
>>> 1) Remove y.tab.c from the original tarball, and ensure the clean method
>>> within Makefile removes it
>>
>> The VMS build procedure c
On 29 September 2014 00:42, Christian Weisgerber wrote:
> They also have a dependency on the bison port, because parse.y does
> not build correctly with FreeBSD's yacc(1). You end up with a bash
> that has broken $(...) parsing. Same issue on OpenBSD, where the
> port doesn't touch parse.y beca
Mark Goldfinch:
> Can someone clarify to me why y.tab.c is included within the bash source
> tree if it is generated from parse.y?
>
> If one looks in the FreeBSD ports tree, they're deliberately taking the
> initiative to touch parse.y to ensure that y.tab.c is always rebuilt.
They also have a
Greetings,
On 28 Sep 2014 19:41, "John E. Malmberg" wrote:
>
> On 9/27/2014 6:49 PM, Mark Goldfinch wrote:
>> 1) Remove y.tab.c from the original tarball, and ensure the clean method
>> within Makefile removes it
>
> The VMS build procedure currently needs the y.tab.c file, as the tools to
build
On 9/27/2014 6:49 PM, Mark Goldfinch wrote:
Hi everyone,
Can someone clarify to me why y.tab.c is included within the bash source
tree if it is generated from parse.y?
Not all platforms have up to date tools for generating y.tab.c from parse.y.
Seeing that it appears likely we're going to e
