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: Wed, 13 Dec 2006 20:52:03 -0500 (EST)

On Wed, 13 Dec 2006, Paul Eggert wrote:

> "Joel E. Denny" <address@hidden> writes:
> 
> > So, here's my original proposal again:
> >
> >   1. "/root/path"
> >   2. "./cwd/path"
> >   3. "path/relative/to/install"
> >
> > Your proposal agrees with #1 and #3 and adds --skeleton-path to influence 
> > #3.
> >
> > Would it hurt to also support #2?

I just remembered one place I've seen something like the above.  These are 
different:

  info --file=bison.info
  info --file=./bison.info

Of course:

  info --file=doc/bison.info

is relative to the current directory.  I don't know if that's what Bison 
should do with --skeleton, but maybe.

Info also has a $INFOPATH if necessary.  Shell commands with $PATH is 
similar.

> #2 bothers me because it's a special case of #3 but with a different
> interpretation from #3.

I see your concern, but I'm thinking that anyone intending #3 wouldn't 
write #2.

> How about if the default skeleton path is the directory the grammar
> was found in, followed by the standard Bison skeleton directory?
> That's similar to how '#include "foo.h"' works in C.  A downside of
> this approach is that one cannot refer to the standard Bison skeleton
> file if there's a file with the same name in the working directory,
> but the usual solution for this (#include_next in GCC) is even better 
> than #2 since it works even in include files and even when the include 
> path length is longer than 1.

This is getting complicated.  Is the path concept really useful here?  
Will we ever want to treat skeletons in the same way as library header 
files spread over a list of directories that Bison must search?  In my 
experience, paths can be a source of a lot of confusion.  Most users 
should steer clear of messing with Bison's skeletons anyway, and they 
should just use what Bison provides.  (This philosophy is part of why I 
like Paolo's %language idea.)  I think only those users and developers who 
are intimately familiar with Bison internals will likely mess with the 
skeletons, and they will likely know exactly where the skeleton they want 
is located, so they won't need Bison to search the file system.




reply via email to

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