Akim Demaille <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] {position} {std::string*} filename
> [EMAIL PROTECTED] {position} {std::string*} file
> The name of the file. It will always be handled as a pointer, the
> parser will never duplicate nor deallocate it. As an experimental
> feature you may change it to @[EMAIL PROTECTED] using @samp{%define
> -"filename_type" "@var{type}"}.
> +"file_type" "@var{type}"}.
> @end deftypemethod
>
> This is wrong, unless you adjust lalr1.cc.
Yes, thanks, I did that. lalr1.cc and bison.texinfo now both use
file_name_type.
> > 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.
2002-06-18 Akim Demaille <[EMAIL PROTECTED]>
* src/files.c (compute_base_names): When computing the output file
names from the input file name, strip the directory part.
--- src/files.c 14 Jun 2002 17:36:24 -0000 1.73
+++ src/files.c 18 Jun 2002 12:39:54 -0000 1.74
@@ -384,11 +384,11 @@ compute_base_names (void)
else
{
/* Otherwise, the short base name is computed from the input
- grammar: `foo.yy' => `foo'. */
+ grammar: `foo/bar.yy' => `bar'. */
filename_split (infile, &base, &tab, &ext);
short_base_name =
- xstrndup (infile,
- (strlen (infile) - (ext ? strlen (ext) : 0)));
+ xstrndup (base,
+ (strlen (base) - (ext ? strlen (ext) : 0)));
}
/* In these cases, always append `.tab'. */
