Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> 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?
>
> I suppose so, yes.
>
> Isn't this a generic pr
Jim Meyering <[EMAIL PROTECTED]> writes:
> 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?
I suppose so, yes.
Isn't this a generic problem that has been around for years?
For example,
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> 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 Ema
Jim Meyering <[EMAIL PROTECTED]> 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 ge
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> > 2) For the user who needs to fix a compilation problem, or do minor
>> >developments in a package.
>> >
>> >In this case I _do_ want to change the Makefile or config.h, to see
>> >the results. Because if I change Makefil
Jim Meyering wrote:
> > 2) For the user who needs to fix a compilation problem, or do minor
> >developments in a package.
> >
> >In this case I _do_ want to change the Makefile or config.h, to see
> >the results. Because if I change Makefile.am or *.m4, I will have to
> >wait 5 minu
Jim Meyering wrote:
> >> Bruno, would you mind if I changed the uses of "t-$@" to "[EMAIL
> >> PROTECTED]"
> >> in modules/localcharset?
> >
> > Yes. The rule would not work right any more on 8+3 filesystems (DJGPP,
> > possibly also OS/2).
>
> Do you know of actual users who have to _build_ GNU
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> alloca.h: alloca_.h
>> rm -f [EMAIL PROTECTED] $@
>> cp $(srcdir)/alloca_.h [EMAIL PROTECTED]
>> chmod a-x [EMAIL PROTECTED]
>> mv [EMAIL PROTECTED] $@
>
> One other thing -- how about if we j
Bruce Korb <[EMAIL PROTECTED]> writes:
> Ralf Wildenhues wrote:
>> [ adding automake-patches ]
>>
>> * Simon Josefsson wrote on Thu, Sep 07, 2006 at 04:56:02PM CEST:
>>
>>>Bruce Korb <[EMAIL PROTECTED]> writes:
>>>
Ralf Wildenhues wrote:
>The fix is to
> find FOOPKG-x.y.z -e
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>> If it's really a major annoyance, you should switch to
>> an editor that lets you circumvent such things more easily.
>> In Emacs, C-xC-q is the typical binding to toggle read-only.
>> For Vi, to save a file owned
Paul Eggert wrote:
And perhaps other people use other editors; we can't really expect
everyone to switch to Emacs or VIM.
No. The "ro" markers just raised the threshhold against editing
these generated things a tiny bit. It doesn't stop anybody. :)
Jim Meyering <[EMAIL PROTECTED]> writes:
> If it's really a major annoyance, you should switch to
> an editor that lets you circumvent such things more easily.
> In Emacs, C-xC-q is the typical binding to toggle read-only.
> For Vi, to save a file owned by you, in spite of its read-only
> setting,
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> I've always taken the stand that
>> generated files should be read-only, and this is just another
>> reason to follow that policy.
>
> I'm vehemently opposed to such a change. On the contrary, I think the
> policy should be that in a
Bruce Korb <[EMAIL PROTECTED]> wrote:
> Bruno Haible wrote:
>> Jim Meyering wrote:
>>
>>>I learned long enough ago that
>>>files like Makefile, Makefile.in, configure, etc. are generated,
>>>so that their being writable isn't a big deal. But still, for
>>>novices, ...
>> Would it help you if we co
Paul Eggert wrote:
> Here's another thought: how about this even-shorter version instead?
>
> alloca.h: alloca_.h
> $(LN_F_S) $(srcdir)/alloca_.h $@
>
> where $(LN_FS) expands to "ln -fs" in the typical case, or to
> "rm -f $@ && cp" on hosts where "ln -fs" doesn't work (e.g., Solaris 9
> a
Bruce Korb wrote:
> Or maybe both of these lines :)
>
>-*- buffer-read-only: t -*- vi: set ro:
>DO NOT EDIT! GENERATED AUTOMATICALLY!
For the user who wants to do small developments, such as tweaks in a
Makefile or config.h, and who happens to use emacs or vi, this is still
a nuisance. (L
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>> alloca.h: alloca_.h
>> $(LN_F_S) $(srcdir)/alloca_.h $@
>>
>> where $(LN_FS) expands to "ln -fs" in the typical case, or to
>> "rm -f $@ && cp" on hosts where "ln -fs" doesn't work (e.g., Solaris 9
>> and earlier).
>
> I like it, but it runs a b
Bruno Haible wrote:
Jim Meyering wrote:
I learned long enough ago that
files like Makefile, Makefile.in, configure, etc. are generated,
so that their being writable isn't a big deal. But still, for
novices, ...
Would it help you if we consequently mark every generated file (except
generated
Jim Meyering wrote:
> I learned long enough ago that
> files like Makefile, Makefile.in, configure, etc. are generated,
> so that their being writable isn't a big deal. But still, for
> novices, ...
Would it help you if we consequently mark every generated file (except
generated doc - info, html,
Hello Paul,
* Paul Eggert wrote on Thu, Sep 07, 2006 at 06:13:11PM CEST:
>
> Here's another thought: how about this even-shorter version instead?
>
> alloca.h: alloca_.h
> $(LN_F_S) $(srcdir)/alloca_.h $@
>
> where $(LN_FS) expands to "ln -fs" in the typical case, or to
> "rm -f $@ && cp"
Ralf Wildenhues wrote:
> [ adding automake-patches ]
>
> * Simon Josefsson wrote on Thu, Sep 07, 2006 at 04:56:02PM CEST:
>
>>Bruce Korb <[EMAIL PROTECTED]> writes:
>>
>>>Ralf Wildenhues wrote:
>>>
>>>
The fix is to
find FOOPKG-x.y.z -exec chmod u+rwx \{\} \; && rm -rf FOOPKG-x.y.z
>
>
>
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> [ adding automake-patches ]
>
> * Simon Josefsson wrote on Thu, Sep 07, 2006 at 04:56:02PM CEST:
>> Bruce Korb <[EMAIL PROTECTED]> writes:
>> > Ralf Wildenhues wrote:
>> >
>> >> The fix is to
>> >> find FOOPKG-x.y.z -exec chmod u+rwx \{\} \; && rm -r
[ adding automake-patches ]
* Simon Josefsson wrote on Thu, Sep 07, 2006 at 04:56:02PM CEST:
> Bruce Korb <[EMAIL PROTECTED]> writes:
> > Ralf Wildenhues wrote:
> >
> >> The fix is to
> >> find FOOPKG-x.y.z -exec chmod u+rwx \{\} \; && rm -rf FOOPKG-x.y.z
> I was just about to suggest that the
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * fsusage.m4 (gl_FILE_SYSTEM_USAGE): Don't use plain echo.
Thanks for catching that; I installed it.
Jim Meyering <[EMAIL PROTECTED]> writes:
> Do you know anyone who prefers that their generated files be writable?
Well, me for starters (:-). It's a minor style thing, but I prefer
that files be marked readonly only when they are intended to be
unchangeable. Removing a readonly file and replaci
Bruce Korb <[EMAIL PROTECTED]> writes:
> Ralf Wildenhues wrote:
>
>> The fix is to
>> find FOOPKG-x.y.z -exec chmod u+rwx \{\} \; && rm -rf FOOPKG-x.y.z
>
> Hi Ralf,
>
> *The* fix would be: make clobber
I was just about to suggest that the above command should be added as
a documented short-cu
Ralf Wildenhues wrote:
The fix is to
find FOOPKG-x.y.z -exec chmod u+rwx \{\} \; && rm -rf FOOPKG-x.y.z
Hi Ralf,
*The* fix would be: make clobber
That would be more an automake issue than gnulib, but it has irritated
me on more than one occasion. A bit easier:
chmod -R u+w FOOPKG-*.*.
* Ralf Wildenhues wrote on Thu, Sep 07, 2006 at 04:27:56PM CEST:
>
> * fsusage.m4 (gl_FILE_SYSTEM_USAGE): Don't use plain echo.
Darn, I meant this:
Index: m4/fsusage.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/fsusage.m4,v
retr
* Bruce Korb wrote on Thu, Sep 07, 2006 at 04:00:32PM CEST:
> No hidden commands without a good reason for hiding the command.
FWIW, I agree with this notion. More generally, I think that if you
want to make "nicer make output", then I prefer a Linux style that I
(with my bug report reader hat on
Hello Simon,
* Simon Josefsson wrote on Thu, Sep 07, 2006 at 04:24:57PM CEST:
>
> A further rant on that theme: I've been annoyed more than once that
> automake 'distcheck' chmod parts of the FOOPKG-x.y.z/ directory as
> read-only.
>
> Further, it even chmod directories as read-only as well, so
Bruno Haible <[EMAIL PROTECTED]> writes:
> 1) For the user who unpacks and builds a package.
>When he wants to remove the package, he will do "rm -r coreutils-6.2".
>This will start asking questions. So he types Ctrl-C, and does
>"rm -rf coreutils-6.2". And next time he will possibly u
Bruno Haible <[EMAIL PROTECTED]> writes:
>> Note that this does affect modules/* files owned by others.
>> If anyone objects, I'll quickly revert the objectionable change.
>
> Please revert. It is not acceptable for me to have read-only files in a
> gettext or libiconv distribution.
I agree with
Jim Meyering wrote:
> Considering the numerous uses of sed and echo (in place of cp)
> I preferred to be consistent. But I agree that it'd be better
> not to pollute the build output with output that is 99% irrelevant.
> So, how about prefixing each new line with "@", so make doesn't print them.
Jim Meyering wrote:
> I've always taken the stand that
> generated files should be read-only, and this is just another
> reason to follow that policy.
I'm vehemently opposed to such a change. On the contrary, I think the
policy should be that in a distrib tarball, _all_ files and directories
shoul
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> alloca.h: alloca_.h
>> rm -f [EMAIL PROTECTED] $@
>> cp $(srcdir)/alloca_.h [EMAIL PROTECTED]
>> chmod a-x [EMAIL PROTECTED]
>> mv [EMAIL PROTECTED] $@
>
> One other thing -- how about if we j
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>
>> alloca.h: alloca_.h
>> rm -f [EMAIL PROTECTED] $@
>> cp $(srcdir)/alloca_.h [EMAIL PROTECTED]
>> chmod a-x [EMAIL PROTECTED]
>> mv [EMAIL PROTECTED] $@
>
> Surely you meant a-w, not a-x.
Yes
Jim Meyering <[EMAIL PROTECTED]> writes:
> alloca.h: alloca_.h
> rm -f [EMAIL PROTECTED] $@
> cp $(srcdir)/alloca_.h [EMAIL PROTECTED]
> chmod a-x [EMAIL PROTECTED]
> mv [EMAIL PROTECTED] $@
One other thing -- how about if we just remove the 'chmod' entirely?
If the source
Jim Meyering <[EMAIL PROTECTED]> writes:
> alloca.h: alloca_.h
> rm -f [EMAIL PROTECTED] $@
> cp $(srcdir)/alloca_.h [EMAIL PROTECTED]
> chmod a-x [EMAIL PROTECTED]
> mv [EMAIL PROTECTED] $@
Surely you meant a-w, not a-x.
Now that so many lib/*.[ch] files in coreutils are generated,
it is harder for me to know when a file comes from gnulib and
when I can modify it in place. I've always taken the stand that
generated files should be read-only, and this is just another
reason to follow that policy. [ I learned long e
39 matches
Mail list logo
