Re: ensure that generated files are read-only

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>
>> I'm surprised that the compromise of adding advisory comments rubs
>> you (Bruno) so hard the wrong way.  Does anyone else object to
>> adding both lines?
>
> I'm afraid I'm mildly annoyed by them too.  I use Emacs with (setq
> enable-local-variables 0), so I get this prompt:
>
>   Set local variables as specified in -*- line of foo.c (y or n)
>
> when I visit a file, and this means my typehead can get
> misinterpreted.  If the file name is sufficiently long and my window
> sufficiently narrow, the screen hops around a bit too, which is
> visually distracting.  I'd rather have a solution that didn't involve
> that question.  (I realize I can shut it off for all files, but that
> has other negative consequences.)
>
> Also, these changes mean I can't easily copy files from coreutils back
> to gnulib; I have to remember to remove the DO NOT EDIT notice.

Good point.

> Again, no big deal, but it's one other minor thing to do (or forget to
> do :-).  Currently, 346 files shared between gnulib and coreutils have
> the DO NOT EDIT notice, so it's quite likely I'll run into the
> problem.
>
> Since the gnulib and coreutils copies are now identical in most cases
> except for the DO NOT EDIT notice, I was thinking of having
> "bootstrap" use symbolic links instead of copies, for source files
> whose contents are identical if you omit the DO NOT EDIT notice.  This
> would mean I'd edit my gnulib copy if I visit my coreutils copy, which
> is almost always what I want to do.  It might also mean another
> annoying question about whether I want to follow a symbolic link to a
> CVS controlled file, but I have fewer qualms about shutting that
> message off.

That sounds like a good alternative for coreutils' bootstrap script.
You're welcome to change it.

However, aren't the warning and possible annoyance at least a little more
appropriate for the build-generated files whose rules I was proposing
to change in gnulib?  Whatever.  If you disagree, I won't lose any
sleep over the status quo.