Re: warn about conflicting skeleton-generated files

[Hans Aberg]

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