Re: [PATCH] Implement clean output file naming rules for %language.

[Paolo Bonzini]

Joel E. Denny wrote:
> On Tue, 7 Oct 2008, Joel E. Denny wrote:
> 
>> Di-an's email has prompted me to change the way Bison computes output file 
>> names.  I'd appreciate any opinions from other developers as well on this 
>> issue.  I feel we need to settle it before the 2.4 release so we don't 
>> find ourselves stuck with more backward compatibility problems.
> 
> I didn't realize how difficult this would be until I got into it.  This is 
> a significant change that could affect many people, so it really needs one 
> more pair of eyes at the very least.
> 
> We should encourage people to use %language, which, 
> after this patch, will activate a simplified and more general set of 
> naming rules.

It seems okay (I only skimmed output.c, concentrating on the m4 and
texinfo parts), and definitely an improvement.  Thanks very much.

However, the part on "how to write a new language" seems uselessly
detailed, and that's a symptom of two problems.

First, you wrote it as a developer and not as a user, but you tried
anyway to think as a user.  This caused some quirks; for example, you
can assume that anyone writing a skeleton for a new language is
comfortable enough working in the Bison build tree, and would start
patching getargs.c to add his language (I did so -- actually I
*implemented* %language :-) at the beginning of my Java skeleton
project, even before starting the m4 parts) and by writing the *-skel.m4
back-end file.

Second, you are not considering the common use case, and are hoping that
people *will* transition to %language.  My experience with developer
tools (Autoconf and Bison especially) tells me that this is harder than
you think.  Most people are using either -o or ylwrap (which uses -y and
implement sane naming on top of that), and those people already have
sane names.  They won't understand why they should require a brand-new
Bison.

I'll try to make a suggestion: besides -y, which is anyway a
compatibility mode, we can assume that most users are probably using *a
-o option that does not specify a filename ending in .tab or _tab, and
have the grammar in a .y file*.

The only difference with the new rules, then, is in how the defines file
is named (with a fixed .h/.hh extension, or instead by changing c's to
h's in the -o file).

* Is this true?  If not, can we make this true at least for C and C++ by
changing the new conventions?

* Does it make sense to change the new convention so that the "change c
to h" part holds also in that case?

* Can we then rewrite the documentation saying that -o, with a filename
not ending in .tab or _tab, follows the new conventions?

* Maybe can we make this true in the implementation, rather than just
write the documentation to match?  Even if it adds a few lines of code,
I believe it's worthwhile because it means that 99% of the executions
would actually follow the new execution path (and the old one would be
tested by -y and by the testsuite).

> I think it would be cleaner if we could change %skeleton to activate the 
> new naming rules as well.  However, I worry this might break makefiles for 
> users who have already been using %skeleton "lalr1.cc", so I didn't do 
> that.  But I'm open to it if others think this isn't an issue.

I wouldn't worry much about %skeleton, a quick Google Code Search says
there's no change there.  So, for this I would say go ahead.  And in
fact, I think we can change the Texinfo documentation assuming that no
one ever used it except people anyway involved in the development of
Bison (and mention changes in NEWS only).  It would be a separate patch,
but one that would also simplify some things.

In other words: I think this is worthwhile, and ought to be done
definitely before the first stable release that supports %language comes
out.  However, it needs some more thought.

Paolo