Eric Blake wrote:
> We could also check at configure time for AC_CHECK_SIZEOF([mode_t]), then
> use the preprocessor to skip the unneeded branch altogether using the
> appropriate macro from config.h.
Yes. Paul Eggert tried to avoid configure-time checks that could also be done
at compile-time. Bu
Bruno Haible clisp.org> writes:
> I'm convinced now. Thanks for showing these effects. Probably I got
> confused by the name and it should better be called m4_concat_args.
> For a single argument, even unquoted, m4_quote appears to be a nop:
It depends on whether that single argument is an unquo
Eric Blake wrote:
> m4_defn is GUARANTEED to be quoted, to
> begin with. All m4_quote does is add quoting to unquoted arguments
It also combines arguments. But here only one argument is passed.
> $ cd autoconf
> $ echo 'm4_divert[]m4_define([a],[A])m4_define([foo], [a[a[a]]])dnl
> > fo
Ben Pfaff cs.stanford.edu> writes:
> > +[/* Define as the maximum value of type 'size_t', if the system doesn't
define
> > + it. */
> > +#ifndef SIZE_MAX
> > +# undef SIZE_MAX
> > +#endif])
> > ])
>
> This logic looks wrong.
Taken out of context, yes, it looks wrong. Which is why Bruno als
Bruno Haible writes:
> +[/* Define as the maximum value of type 'size_t', if the system doesn't
> define
> + it. */
> +#ifndef SIZE_MAX
> +# undef SIZE_MAX
> +#endif])
> ])
This logic looks wrong.
--
"Premature optimization is the root of all evil."
--D. E. Knuth, "Structured Programming wi
Bruno Haible clisp.org> writes:
> > By the way, m4_quote(m4_defn([foo])) is overkill - m4_defn already properly
> > quotes its output as a single m4 argument, so the m4_quote is a no-op
(m4_quote
> > is only useful when collecting multiple unquoted m4 arguments into a single
> > string).
>
>
Eric Blake wrote:
> I think I see a logic bug in this patch which explains why Jens Rehsack still
> saw a failure in m4 1.4.13:
>
> > +++ lib/math.in.h 2008-11-20 23:26:08.0 +0100
> > @@ -22,7 +22,7 @@
> > #endif
> >
> > /* The include_next requires a split double-inclusion guard. *
Simon Josefsson wrote:
> Bruno, what do you think about simply deprecating the size_max module?
This would cause problems in libintl. The intl/ directory, when shipped
as part of a package that used gettextize, should not create its own copy
of stdint.h. But the intl/ directory contains vasnprintf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Sergey Poznyakoff on 5/21/2009 3:07 AM:
> Hello,
>
> How about the following patch, which adds support for `silent-rules'
> mode introduced in Automake 1.11:
>
> * build-aux/bootstrap (slurp): Add silent rule support to $gnulib_mk,
> if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 5/20/2009 5:08 PM:
> You can ignore this warning. The code is fine.
>
> We know no way of getting rid of this warning, except by passing fewer warning
> options to gcc.
We could also check at configure time for AC_CHECK_S
Simon Josefsson wrote:
> The getdelim module already implicitly depends on stdint
I don't think it did. 'realloc-posix' depends on stdlib, not stdint.
So what you added is a new dependency.
Some people, like Sam Steingold, want to minimize dependencies in gnulib.
Especially towards module 'stdint
Ralf Wildenhues ha escrit:
> Not as far as I can see. Solaris /bin/awk doesn't have the match and
> sub functions, and has several other limitations over POSIX awk.
Ah, I see.
> On Solaris, you should be able to use nawk or /usr/xpg4/bin/awk.
OK, then using ${AWK-awk} should do to help in thi
* Sergey Poznyakoff wrote on Thu, May 21, 2009 at 11:58:15AM CEST:
> > FWIW the awk script is not portable to ancient awk, such as found on
> > Solaris.
>
> Hmm, but why? I didn't use any GNU awk extensions, did I?
Not as far as I can see. Solaris /bin/awk doesn't have the match and
sub functio
Ralf Wildenhues ha escrit:
> - the awk script won't detect if there are already $(AM_V_...) variables
> present in the rules,
Yes, that's intended. It was supposed that silent-rules variables can
not appear in the input.
Regards,
Sergey
Pádraig Brady wrote:
>
> I noticed another thread with more info about fallocate:
> https://www.redhat.com/archives/fedora-devel-list/2009-April/msg00110.html
>
> That got me thinking about whether we should use fallocate()
> if available in cp etc. so ext4 etc. can allocate optimally?
Here is a
Hi Ralf,
> Can gnulib-tool create
> target1 target2 ... \
> targetN : prereq1 ... \
> prereqN ; rule-command
>
> rules?
Well, quick grep through modules/* shows that so far no module
generates such rules. But in theory it is possible. I'll take
it into account, then.
> Sho
Ralf Wildenhues wrote:
> A couple more data points:
>
> - the awk script won't detect if there are already $(AM_V_...) variables
> present in the rules,
>
> - the script won't cope with some of the more elaborate GNU
> make-specific constructs; this is probably totally irrelevant for
> gnulib
Sergey Poznyakoff wrote:
> How about the following patch, which adds support for `silent-rules'
> mode introduced in Automake 1.11:
>
> * build-aux/bootstrap (slurp): Add silent rule support to $gnulib_mk,
> if required by the configure.ac.
Hi Sergey,
Nice.
I did something similar using perl, but
A couple more data points:
- the awk script won't detect if there are already $(AM_V_...) variables
present in the rules,
- the script won't cope with some of the more elaborate GNU
make-specific constructs; this is probably totally irrelevant for
gnulib, but not for:
- this could be done
Hi Sergey,
* Sergey Poznyakoff wrote on Thu, May 21, 2009 at 11:07:53AM CEST:
> How about the following patch, which adds support for `silent-rules'
> mode introduced in Automake 1.11:
Neat idea. :-)
> +# AWK program to convert a Makefile(.am) file rules to Automake 1.11
> +# silent mode.
> +si
Hello,
How about the following patch, which adds support for `silent-rules'
mode introduced in Automake 1.11:
* build-aux/bootstrap (slurp): Add silent rule support to $gnulib_mk,
if required by the configure.ac.
---
build-aux/bootstrap | 49 +
1
Eric Blake ha escrit:
> In earlier versions of POSIX, the intent was that mode_t could
> be narrower than int, and that all programmers had to use only symbolic
> constants in that argument.
As a side note, on that particular architecture, mode_t is indeed
narrower than int.
Regards,
Sergey
Bruno Haible ha escrit:
> You can ignore this warning. The code is fine.
Ah, OK. Thank you. Perhaps it merits mentioning in the docs,
to avoid further reports of this kind?
Regards,
Sergey
23 matches
Mail list logo
