bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: warn about conflicting skeleton-generated files


From: Joel E. Denny
Subject: Re: warn about conflicting skeleton-generated files
Date: Thu, 14 Dec 2006 16:18:31 -0500 (EST)

On Thu, 14 Dec 2006, Hans Aberg wrote:

> > 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. 

It is the same: if the file name contains a `/' and it's a relative file 
name, it's relative to where the user specifies the file name.

Consider the alternatives.  I think the user invoking `bison 
--skeleton=FILE_NAME' would find it confusing if the FILE_NAME were 
relative to the grammar file.  I think the user specifying `%skeleton 
"FILE_NAME"' in the grammar file would find it confusing if the file name 
were relative to wherever Bison happened to be invoked.  Of course, all of 
this is moot if the user invokes Bison in the grammar file's directory, 
and I suspect that is what happens most of the time.

> Therefore, perhaps Paul's idea
>   %skeleton "<name>"
>   %skeleton <<name>>
> might be used.

This was not Paul's idea.  This was my misunderstanding of his idea.

> 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.

Again, I think this is more complexity than we need.

> > 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.

Most people are used to writing commands at a shell prompt, so my proposal 
should be fine in that regard, and I think it's simpler:

1. If the file name does not contain a `/', it's one of Bison's installed 
skeleton files.

2. If the file name does contain a `/', it's an absolute or relative file 
name.  If it's relative, it's relative to where the file name was 
specified (current working directory for the command-line, and grammar 
file directory for the grammar file).




reply via email to

[Prev in Thread] Current Thread [Next in Thread]