>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>> > I noticed that the Bison documentation disagreed with the behavior >> > with respect to whether "bison dir/foo.y" creates foo.tab.c or >> > dir/foo.tab.c, and decided to change the documentation to match the >> > behavior. >> >> This is really a bad behavior. I'd rather fix the behavior than the >> documentation. > I preferred the old behavior too, but was cautious about changing it > just before Bison 2.1 came out. Can you please explain why you > changed it to the current behavior? Here's the patch that did it. > Thanks. My bad, I misunderstood what was going on: the current behavior is the right one and the documentation was to be fixed. No tool is known to output in the same directory as its input, especially not compilers. ISTR this was pointed to me by Jim, or was it Alexandre? That's the way byacc and the others behave too. And I guess that that's what POSIX wants. I'm confused with the fact that /tmp % bison -S lalr1.cc bar/foo.y -o bar/foo.cc nostromo 13:40 /tmp % ls -l bar nostromo 13:40 total 24 -rw-r--r-- 1 akim lrde 17801 2005-09-15 13:40 foo.cc -rw-r--r-- 1 akim lrde 15 2005-09-15 13:39 foo.y /tmp % bison -S lalr1.cc bar/foo.y -o bar/foo.cc -d -v nostromo 13:41 /tmp % ls -l bar nostromo 13:41 total 40 -rw-r--r-- 1 akim lrde 17823 2005-09-15 13:41 foo.cc -rw-r--r-- 1 akim lrde 8506 2005-09-15 13:41 foo.hh -rw-r--r-- 1 akim lrde 582 2005-09-15 13:41 foo.output -rw-r--r-- 1 akim lrde 15 2005-09-15 13:39 foo.y /tmp % ls position.hh location.hh stack.hh nostromo 13:41 location.hh position.hh stack.hh These are wrong.
