[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: warn about conflicting skeleton-generated files
From: |
Hans Aberg |
Subject: |
Re: warn about conflicting skeleton-generated files |
Date: |
Thu, 14 Dec 2006 21:39:13 +0100 |
On 14 Dec 2006, at 19:08, Joel E. Denny wrote:
When I checked it (the right way) in 2.3a, there seems to be no
difference:
they are always relative the /usr/local/share/bison/ directory in my
installation.
That's what it is.
There, I want a way to make it relative the directory 'bison'
was invoked.
For --skeleton, this is what I think it should be. For %skeleton,
I think
it makes more sense for it to be relative to the grammar file,
which is
where the %skeleton is located. In other words, I think it should
always
be relative to where you specified the file name.
I think any duplication %<name> and --<name> should be the same -
anything else would be confusing. Therefore, perhaps Paul's idea
%skeleton "<name>"
%skeleton <<name>>
might be used. The latter form would then always be relative '/usr/
local/share/bison/' or where Bison puts its skeleton files. The
former form would first search the Bison invocation directory, unless
set different by some variable, and if that fails, search as the
second form.
I propose:
1. If the file name does not contain `/', prepend `pkgdatadir/'.
2. If it does, don't.
So this might suffice for that. But what if one writes
%skeleton "my/lalr.cc"
Would one not expect it to work like
%skeleton "lalr.cc"
but checking in the subdirectory "my"?
You mean checking in /usr/local/share/bison/my/ (the pkgdatadir)?
That
was also my original intuition, which is strange since I can't
think of
any precedent that agrees with both it and the rest of my
proposal. That
is, shell command lookup and `info --file' treat the file name as
relative
to the current directory simply because it contains a `/'.
I probably misunderstood, and reversed the two above in my
interpretation.
I agree with Paul that following some widespread precedent has
value when
it comes to something as common as specifying a file name.
Paul's suggestion would make Bison behave as a C/C++ compiler. It
does not cover absolute paths. It might be covered if the first form
above does not prepend anything. Having no quotes in --skeleton would
behave as the second form above, for legacy.
What about that? - It would create something people are already used to.
Hans Aberg
- Re: warn about conflicting skeleton-generated files, (continued)
- Re: warn about conflicting skeleton-generated files, Paul Eggert, 2006/12/13
- Re: warn about conflicting skeleton-generated files, Joel E. Denny, 2006/12/13
- Re: warn about conflicting skeleton-generated files, Paul Eggert, 2006/12/13
- Re: warn about conflicting skeleton-generated files, Joel E. Denny, 2006/12/13
- Re: warn about conflicting skeleton-generated files, Paul Eggert, 2006/12/13
- Re: warn about conflicting skeleton-generated files, Joel E. Denny, 2006/12/13
- Re: warn about conflicting skeleton-generated files, Paul Eggert, 2006/12/14
- Re: warn about conflicting skeleton-generated files, Joel E. Denny, 2006/12/14
- Re: warn about conflicting skeleton-generated files, Hans Aberg, 2006/12/14
- Re: warn about conflicting skeleton-generated files, Joel E. Denny, 2006/12/14
- Re: warn about conflicting skeleton-generated files,
Hans Aberg <=
- Re: warn about conflicting skeleton-generated files, Joel E. Denny, 2006/12/14
- Re: warn about conflicting skeleton-generated files, Hans Aberg, 2006/12/13
- Re: warn about conflicting skeleton-generated files, Joel E. Denny, 2006/12/13
- Re: warn about conflicting skeleton-generated files, Hans Aberg, 2006/12/13
- Re: warn about conflicting skeleton-generated files, Joel E. Denny, 2006/12/13
- Re: warn about conflicting skeleton-generated files, Hans Aberg, 2006/12/13
- Re: warn about conflicting skeleton-generated files, Joel E. Denny, 2006/12/13
- Re: warn about conflicting skeleton-generated files, Hans Aberg, 2006/12/13
- Re: warn about conflicting skeleton-generated files, Joel E. Denny, 2006/12/14