Re: Get rid of ylwrap, and simplify yacc/lex rules (was: Re: FYI: maint: fix the generation of the synclines for bison's parser)

[Akim Demaille]

Le 6 mai 2012 à 12:38, Stefano Lattarini a écrit :

> Severity: wishlist
> 
> [Adding bug-automake in CC:]
> 
> Hi Akim.
> 
> On 05/06/2012 11:20 AM, Akim Demaille wrote:
>> This is taken from master.  I work with a VPATH build, and the
>> generated synclines are very wrong.  Probably something that
>> ylwrap should handle better btw.

On second thought, this is unfair to ylwrap.  The issue is
rather that bison issues synclines which are relative the
cwd instead of relative to the path of the output file.

/tmp $ echo "%% exp: 'a' { action(); };" > in/in.y
/tmp $ bison in/in.y -o out/out.c
/tmp $ grep '^#line' out/out.c
#line 70 "out/out.c"
#line 105 "out/out.c"
#line 1 "in/in.y"
#line 1310 "out/out.c"
#line 1315 "out/out.c"

Both "out/out.c" and "in/in.y" are wrong.  They should be
"out.c" and "../in/in.y".

This is why bison gets (in my VPATH-build where builddir is two
levels down inside srcdir):

#line 277 "parse-gram.y"
#line 2271 "../../../src/parse-gram.c"

with a properly computed relative path, it should be
"parse-gram.c".  This is what the patch was fixing.

This is painful and regularly results in Emacs not being able
to find the file where the error occurred.

This should be fixed before 2.5.1 imho.  I'll see if gnulib
offers something to compute relative paths.

> Or maybe we could get rid of ylwrap and assume yacc/lex support the
> '-o' option.  After all:
> 
>  - the yacc- and lex-generated files are automatically distributed,
>    so only the maintainers should be expected to regenerate them;
> 
>  - the sytem yacc on OpenBSD and NetBSD (not surre yet about FreeBSD,
>    will check) support the '-o' option as well; and their lex too,
>    since its flex
> 
>  - supporting proprietary yacc and lex should be low-priority IMHO.
> 
> Might this be something to consider for Automake 1.13?

I have no strong opinion about this.  But I like simplifications :)