Future/bison
1
0
Fork 0
mirror of https://git.savannah.gnu.org/git/bison.git synced 2026-03-09 04:13:03 +00:00
Code Issues Packages Projects Releases Wiki Activity

* src/files.c (compute_base_names): When computing the output file

Browse Source 
names from the input file name, strip the directory part.
This commit is contained in:
Akim Demaille
2002-06-18 12:39:54 +00:00
parent ca98bf5758
commit 8c165d891d
4 changed files with 13 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
ChangeLog
View File

@@ -1,3 +1,8 @@
2002-06-18 Akim Demaille <akim@epita.fr>
* src/files.c (compute_base_names): When computing the output file
names from the input file name, strip the directory part.
2002-06-18 Akim Demaille <akim@epita.fr>
* data/bison.simple.new: Comment changes.

5
NEWS
View File

@@ -3,6 +3,11 @@ Bison News
Changes in version 1.49b:
* Output Directory
When not in Yacc compatibility mode, when the output file was not
specified, runnning `bison foo/bar.y' created `foo/bar.c'. It
now creates `bar.c'.
* Undefined token
The undefined token was systematically mapped to 2 which prevented
the use of 2 from the user. This is no longer the case.

71
TODO
View File

@@ -75,77 +75,6 @@ Paul notes:
PDP-10 ports :-) but they should probably be documented
somewhere.
* Output directory
Akim:
| I consider this to be a bug in bison:
|
| /tmp % mkdir src
| /tmp % cp ~/src/bison/tests/calc.y src
| /tmp % mkdir build && cd build
| /tmp/build % bison ../src/calc.y
| /tmp/build % cd ..
| /tmp % ls -l build src
| build:
| total 0
|
| src:
| total 32
| -rw-r--r-- 1 akim lrde 27553 oct 2 16:31 calc.tab.c
| -rw-r--r-- 1 akim lrde 3335 oct 2 16:31 calc.y
|
|
| Would it be safe to change this behavior to something more reasonable?
| Do you think some people depend upon this?
Jim:
Is it that behavior documented?
If so, then it's probably not reasonable to change it.
I've Cc'd the automake list, because some of automake's
rules use bison through $(YACC) -- though I'll bet they
all use it in yacc-compatible mode.
Pavel:
Hello, Jim and others!
> Is it that behavior documented?
> If so, then it's probably not reasonable to change it.
> I've Cc'd the automake list, because some of automake's
> rules use bison through $(YACC) -- though I'll bet they
> all use it in yacc-compatible mode.
Yes, Automake currently used bison in Automake-compatible mode, but it
would be fair for Automake to switch to the native mode as long as the
processed files are distributed and "missing" emulates bison.
In any case, the makefiles should specify the output file explicitly
instead of relying on weird defaults.
> | src:
> | total 32
> | -rw-r--r-- 1 akim lrde 27553 oct 2 16:31 calc.tab.c
> | -rw-r--r-- 1 akim lrde 3335 oct 2 16:31 calc.y
This is not _that_ ugly as it seems - with Automake you want to put
sources where they belong - to the source directory.
> | This is not _that_ ugly as it seems - with Automake you want to put
> | sources where they belong - to the source directory.
>
> The difference source/build you are referring to is based on Automake
> concepts. They have no sense at all for tools such as bison or gcc
> etc. They have input and output. I do not want them to try to grasp
> source/build. I want them to behave uniformly: output *here*.
I realize that.
It's unfortunate that the native mode of Bison behaves in a less uniform
way than the yacc mode. I agree with your point. Bison maintainters may
want to fix it along with the documentation.
* Unit rules
Maybe we could expand unit rules, i.e., transform

6
src/files.c
View File

@@ -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'. */