Re: filenaming with .yxx extensions

[Akim Demaille]

| On Thu, 2002-02-28 at 00:53, Paul Eggert wrote:
| > > From: Akim Demaille <address@hidden>
| > > Date: 27 Feb 2002 09:36:55 +0100
| > 
| > > bison --define=foo.z -o foo.x foo.y
| > 
| > This seems like it would be an adequate workaround for OpenOffice.org.
| > If they use this:
| > 
| > bison -d -o .../rscyacc.yxx --defines=.../rscyacc.yxx.h rscyac.y
| > 
| 
| I think there is a bug if the --defines=xx is before -o it does not
| work.  It breaks the same as -o alone, so I think Paul is right here.

Err?  I probably don't understand your point:

/tmp/ken % ls -ltr                                               nostromo 15:00
total 32
-rw-r--r--    1 akim     lrde           13 fév 28 15:00 foo.y
-rw-r--r--    1 akim     lrde        29367 fév 28 15:00 foo.x
-rw-r--r--    1 akim     lrde          169 fév 28 15:00 foo.h
/tmp/ken % rm foo.x foo.h                                        nostromo 15:00
/tmp/ken % bison -o foo.x --defines=foo.h foo.y                  nostromo 15:01
/tmp/ken % ls -ltr                                               nostromo 15:01
total 32
-rw-r--r--    1 akim     lrde           13 fév 28 15:00 foo.y
-rw-r--r--    1 akim     lrde        29367 fév 28 15:01 foo.x
-rw-r--r--    1 akim     lrde          169 fév 28 15:01 foo.h


| Bug number 3:

I must have lost one somewhere :)

| I understand gwen has commented as well and you are considering putting
| an error out when defines file = the output file.

More generally, that Bison must detect when it is outputting two files
under twice the same name.  My problem is that I'm also thinking about
the future, where we will have more than 2 files.

| Problem with suggestion:
| 
| It does not run with bison 1.28 OO baseline  (try it).

I know.

| I have however supplied a 1.33 only patch but this is dependant on
| acceptance and forcing an upgrade of all developers, not pretty.

I confess that my favorite reference to prettiness is that of the
concepts, and that I'm attached to backward compatibility when moving
from it is not insignificant (which is how I'm tempted to rank the
present case).  Would you say that you crucially depend upon this
``feature''?