Re: y.tab.c inclusion within the source tree

[Chet Ramey]

On 9/28/14, 4:01 AM, Mark Goldfinch wrote:
> Greetings,
> 
> On 28 Sep 2014 19:41, "John E. Malmberg" <wb8tyw@qsl.net> 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 it on VMS are not current.
> 
> OK - thanks for pointing this out.
> 
> Two questions spring to mind:
> 
> 1) ./configure must learn whether current yacc/bison is present - when it
> does surely it can take action to ensure y.tab.c is always going to be
> produced from parse.y - does this seem reasonable?

It can do the first.  How could it possibly do the second without breaking
the way makefiles are supposed to work?  The way to do this is to use make
and timestamps.

You can't assume that configure is run after running patch.

> 2) Are there other supported build platforms for bash which fall into the
> same category as VMS?  Is it unreasonable to require an officially
> supported build platform to have the required build tools?

I want bash to have few external dependencies.  I can do part of this by
shipping y.tab.c and y.tab.h as part of the distribution.

> There's been discussion about dropping POSIX mode support in a future
> version of bash 

No, there hasn't.


> I raise this as I have met with surprise problems associated with y.tab.c's
> timestamp being newer than parse.y but only having parse.y patched.

And when parse.y gets patched, its timestamp gets updated, making it newer
than y.tab.c.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/