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 probl
Paul Smith wrote:
> I recognize there are some situations where make snippets are really
> the best way, but it seems like they're being used even in places where
> configure.ac would be just as simple. I think it would be a good
> "statement of policy" for gnulib that if there are equivalent ways
On Sun, 2019-09-08 at 16:40 -0700, Paul Eggert wrote:
> Admittedly GNU Make is a special case, since you want to build it
> without having 'make'. And if it's just a few Gnulib modules and
> they're not doing anything fancy, perhaps we can modify the modules
> to use 'configure' substitutions inste
Hi Paul,
> This is a real issue for me because I've always provided a shell
> script, build.sh, which can be used to bootstrap an instance of make if
> the user doesn't already have one.
The information about bootstrapping [1][2] gives a different picture
of bootstrapping. For many packages, nowa
On 9/8/19 2:06 PM, Paul Smith wrote:
Why can't we add
these headers as AC_CONFIG_FILES() and allow them to be generated by
the configure script, instead of requiring makefile rules to do it?
Makefile rules can do things that an Autoconf substitition can't, or at least
can't
I'm looking at allowing GNU make to use more gnulib facilities, but
I've run into a serious problem.
It seems that a lot of gnulib modules rely on makefile rules added to
Makefile.in to construct files, rather than using traditional configure
replacement .in file conversions.
This
On 12/18/2015 05:50 PM, Daiki Ueno wrote:
Assaf Gordon writes:
I'm encountering some build errors during 'make' in projects using gnulib, and
I suspect it has something to do with this commit:
gperf: respect silent rules
http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=30f4290
Assaf Gordon writes:
> I'm encountering some build errors during 'make' in projects using gnulib,
> and I suspect it has something to do with this commit:
>
>gperf: respect silent rules
>
> http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=30f4290277444b1d4825a42c9a33f2c3c7fe310a
>
Hello,
I'm encountering some build errors during 'make' in projects using gnulib, and
I suspect it has something to do with this commit:
gperf: respect silent rules
http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=30f4290277444b1d4825a42c9a33f2c3c7fe310a
The symptom I've found is
23 matches
Mail list logo
