Bruno Haible <[EMAIL PROTECTED]> writes:
> In theory, yes. In practice, we can stop the propagation of 'volatile'
> at function boundaries, for functions we know the compiler will not
> inline. (Only if the compiler inlines a function, it has the chance to
> reorder the statements in ways that wer
Can you suggest a wording?
Delete the (default \"doc\") from the help message, since
evidently it is not so. (Ditto the other dir options, I suppose.)
That was the main thing that misled me.
karl
This is non unanimous; can you please notify the mailing list before
such changes?
Sorry, I thought it was trivial and uncontroversial. Obviously not.
Can you please revert that patch?
Done I hope.
1. Alphabetical order is the worst order, except in an index.
Before, the opt
I would remove the old gnulib/m4/gnulib.m4.
Aha! That solved everything.
Perhaps it would be for gnulib-tool to warn if it sees
gnulib/m4/gnulib.m4. Or perhaps it doesn't matter because no other
gnulib users still have one lying around.
Thanks much,
karl
Eric Blake wrote:
> Would it be worth grepping configure.ac, and if you detect AC_PREREQ([2.60]),
> having that imply --assume-autoconf=2.60?
Yes, excellent idea. There is no need to store the minimum autoconf
version in two different places, in configure.ac and gnulib-cache.m4.
Bruno
Bruno Haible <[EMAIL PROTECTED]> writes:
> I added a --assume-autoconf command line options. You can use
> --assume-autoconf=2.60; 2.59 is the default for now.
Thanks, this is nicer. (Should I set my alarm clock to increment the
default in July 2007? :-)
I'd rather not put '--assume-autoconf=
> A func_begin_table invocation is missing before two paragraphs
> that end with func_end_table; the generated HTML is invalid.
Right, thanks. I won't be able to install a fix for this for about 2
week; if it is urgent, please go ahead.
/Simon
"Derek R. Price" <[EMAIL PROTECTED]> writes:
> Yoann Vandoorselaere wrote:
>> OpenBSD is an example, but there is more, a lot of system doesn't
>> support AI_ADDRCONFIG or other specific flags, and thus would be
>> affected by the same problem.
>
> What version of OpenBSD?
I just now checked Open
Bruno Haible clisp.org> writes:
>
> Paul Eggert wrote on 2006-07-09:
> > While bootstrapping Bison I noticed that gnulib-tool assumes Autoconf
> > versions 2.57 through 2.59. But Bison assumes 2.60. On the theory
> > that gnulib-tool should assume the latest stable version, and you
> > can cop
Karl Berry wrote:
> I wanted to add the Gnulib closeout module to Hello. So I ran
> gnulib-tool --import closeout
>
> It seemed to run fine (importing lots of other modules as dependencies),
> however, closeout.c did not get added to the gnulib Makefile.am (or
> Makefile.in or Makefile), appar
Simon Josefsson wrote:
> --- MODULES.html.sh 12 Jul 2006 15:19:16 - 1.123
> +++ MODULES.html.sh 14 Jul 2006 10:42:44 -
> @@ -2069,13 +2069,21 @@ func_all_modules ()
>func_end_table
>
>element="Support for building documentation"
> - func_section_wrap build_lib
> + func_
Paul Eggert wrote on 2006-07-09:
> While bootstrapping Bison I noticed that gnulib-tool assumes Autoconf
> versions 2.57 through 2.59. But Bison assumes 2.60. On the theory
> that gnulib-tool should assume the latest stable version, and you
> can copy onceonly by hand if you want an earlier one
Hi Karl,
A few days ago you checked in the appended patch.
This is non unanimous; can you please notify the mailing list before
such changes?
In particular, I disagree with the entire patch:
1. Alphabetical order is the worst order, except in an index.
Before, the options were listed in a
Karl Berry wrote:
> A few days ago, gnulib-tool --import (or --update) started reporting
>
> gnulib-tool: *** missing --doc-base option
> gnulib-tool: *** Stop.
>
> The help msg says "doc" is supposed to be used as a default, but
> apparently not. I looked briefly at the script and surmise that
Paul Eggert wrote:
> > On a system where 'unsigned char' and 'int' have the same number of
> > bits, the getc() and fgetc() result EOF would be ambiguous: it could
> > be EOF or it could be a casted 'unsigned char' value. It sounds very
> > improbable that such a system exists, now or in the future
Paul Eggert wrote on 2006-07-05:
> > The rule of thumb is: If a data field can be written by the main program
> > and read by the signal handler, or vice versa, it needs to be marked as
> > 'volatile'.
>
> OK, thanks for explaining it. Though I think you meant that the field
> needs to be accesse
Okay to commit the attached patch in order to have
regexprops-generic.texi import to CVS M4 handled by gnulib-tool?
Or would it be better to make a whole new module for this?
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://blog.a
On Thu, 2006-07-20 at 08:00 -0400, Derek R. Price wrote:
> Yoann Vandoorselaere wrote:
> > OpenBSD is an example, but there is more, a lot of system doesn't
> > support AI_ADDRCONFIG or other specific flags, and thus would be
> > affected by the same problem.
>
> What version of OpenBSD?
The guy
Yoann Vandoorselaere wrote:
> OpenBSD is an example, but there is more, a lot of system doesn't
> support AI_ADDRCONFIG or other specific flags, and thus would be
> affected by the same problem.
What version of OpenBSD?
Regards,
Derek
--
Derek R. Price
CVS Solutions Architect
Get CVS support at
On Thu, 2006-07-20 at 10:17 +0200, Yoann Vandoorselaere wrote:
> On Wed, 2006-07-19 at 11:43 -0400, Derek R. Price wrote:
> > Yoann Vandoorselaere wrote:
> > > My suggestion is that unless we can get a full featured replacement of
> > > the getaddrinfo function within GnuLib (and thus replace any n
On Wed, 2006-07-19 at 13:39 -0400, Derek R. Price wrote:
> Yoann Vandoorselaere wrote:
> > There is a problem with the current version of the getaddrinfo module
> > since on certain system, the getaddrinfo() function is present but
> > certain flags (for example AI_ADDRCONFIG flags) are not availab
On Wed, 2006-07-19 at 11:43 -0400, Derek R. Price wrote:
> Yoann Vandoorselaere wrote:
> > My suggestion is that unless we can get a full featured replacement of
> > the getaddrinfo function within GnuLib (and thus replace any non
> > conforming system implementation), we should not attempt to rede
22 matches
Mail list logo
