On 12/24/21 09:24, Bruno Haible wrote:
It seems to work fine on all platforms I tested:
Linux distros, macOS, FreeBSD, NetBSD, OpenBSD, AIX, Solaris, Minix
(all with the default 'make').
Thanks for testing, and for the review. I installed the patches with
your suggested improvements.
Paul Eggert wrote:
> I haven't installed this patchset into Gnulib, as I want to test it on a
> few more platforms and also would like to hear comments.
It seems to work fine on all platforms I tested:
Linux distros, macOS, FreeBSD, NetBSD, OpenBSD, AIX, Solaris, Minix
(all with the default 'make
Paul Eggert wrote:
> I haven't installed this patchset into Gnulib, as I want to test it on a
> few more platforms and also would like to hear comments.
Comments:
1) In 0001: modules/sed-header should have a section
Applicability:
all
Like e.g. modules/gperf or modules/snippet/arg-nonnull. Why
Paul Eggert wrote:
> I also installed the second attached patch, which adds a couple of
> @NMD@s that were missed earlier.
Thanks. Yes, I missed the ones in modules/libgmp.
Bruno
Paul Eggert wrote:
>SED_HEADER_BEGIN = -n \
> -e 1h \
> -e '1s,.*,/* DO NOT EDIT! GENERATED AUTOMATICALLY! *,w $@-t' \
> -e 1g
>SED_HEADER_END = \
> -e 'w $@-t'
>
> (and we can put comments near this explaining 'sed' to the uninitiated :-).
Yes, these comments are what mak
On 12/21/21 12:12, Bruno Haible wrote:
I'm fine with removing these 'rm -f $@-t $@' commands.
OK, I did that with the first attached patch.
The @NMD@ business means we need recipe lines that say "$(AM_V_GEN)" and
nothing else. However, this should be portable and GNU Make figures it
out with
On Tue, Dec 21, 2021 at 5:21 PM Paul Eggert wrote:
> On 12/21/21 12:23, Jim Meyering wrote:
> > Even with `mv -f` support, one must still either remove $@-t or otherwise
> > ensure that it is writable. The read-only temporary may have been left
> > behind
> > from a preceding, interrupted run of
On 12/21/21 12:23, Jim Meyering wrote:
Even with `mv -f` support, one must still either remove $@-t or otherwise
ensure that it is writable. The read-only temporary may have been left behind
from a preceding, interrupted run of the same rule.
Yes, that's the "(though not perfect)" I alluded to
Paul Eggert wrote:
> My preference is to not do the chmod -w, though, as I've found it to be
> more of a hassle than a help.
Same for me. The first line of the file, with an uppercased warning, is
enough to remind the user that changes to the file are volatile.
Bruno
On Tue, Dec 21, 2021 at 12:12 PM Paul Eggert wrote:
> On 12/21/21 11:50, Jim Meyering wrote:
> > One must delete $@ and the potential $@-t temporary file in any rule
> > that creates a generated file and marks it (as I prefer always to do) as
> > read-only by using chmod to subtract write permissi
Jim Meyering wrote:
> One must delete $@ and the potential $@-t temporary file in any rule
> that creates a generated file and marks it (as I prefer always to do) as
> read-only by using chmod to subtract write permissions.
Ah, like coreutils does! So these 'rm -f $@-t $@' commands are a left-over
On 12/21/21 11:50, Jim Meyering wrote:
One must delete $@ and the potential $@-t temporary file in any rule
that creates a generated file and marks it (as I prefer always to do) as
read-only by using chmod to subtract write permissions.
Otherwise, the attempt to redirect to $@-t (when it is read
On Tue, Dec 21, 2021 at 11:41 AM Paul Eggert wrote:
...
> If you run 'make' sometimes as one user and sometimes as another, you
> can have problems like that no matter what. We don't put 'rm -f $@' at
> the start of every other makefile recipe to work around those problems;
> why are these recipes
On 12/21/21 01:41, Bruno Haible wrote:
The number of developers who know about 'echo', 'cat', and *simple* 'sed'
commands is far larger than the number of developers who know about
advanced 'sed' commands (with hold space etc.).
I'm not all that worried about this issue, as this stuff is boile
Paul Eggert wrote:
> One related topic. Many Gnulib modules list makefile rules containing
> many instances of '&& \' at line ends. How about if we omit the '&& \'
> when that's easy? Something like the attached
There are three problems with this patch:
1) A maintainability problem.
- {
15 matches
Mail list logo
