[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

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/"
Would one not expect it to work like
  %skeleton ""
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

reply via email to

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