Hello Paul,
* Paul Eggert wrote on Sat, Sep 16, 2006 at 10:34:52PM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
>
> > * gnulib-tool (func_exit): New function, to allow to pass the
> > exit status portably through the trap. Use everywhere.
> > (--help, --version): Signal a writ
@unnumbered -> @appendixsec.
Same problem as changing the node name. It would impact all existing
manuals that use gpl.texi, which is a lot. They already have their
node structure set up to assume it's a chapter-level entity.
[EMAIL PROTECTED] License, GNU LGPL
I didn't include this
Bruno Haible <[EMAIL PROTECTED]> writes:
> OSF/1 4.0 declares neither getnameinfo nor getaddrinfo.
>
> OSF/1 5.1 declares both in but has this:
>
> #if defined (_SOCKADDR_LEN) || defined (_XOPEN_SOURCE_EXTENDED)
> #define getaddrinfo ngetaddrinfo
> #else
> #define getaddrinfo ogetaddrinfo
> #endi
Paul Eggert wrote:
> It's a bit weird, though, that Tru64 has getnameinfo declared but
> getaddrinfo is not defined. Is that correct, or am I missing
> something?
OSF/1 4.0 declares neither getnameinfo nor getaddrinfo.
OSF/1 5.1 declares both in but has this:
#if defined (_SOCKADDR_LEN) || def
Paul Eggert wrote:
> Don't you also need to add an #include "configmake.h" line to
> lib/javaversion.c?
Yes, of course. Thank you. Done.
Bruno
Mark D. Baushke wrote:
> It is probably a good idea to just quote the variable
> arguments to test in this case to ensure that the
> '=' operator is used in a binary operator context.
I agree with the first line of your patch, but not with the second one.
Blindly putting double-quotes around varia
Eric Blake <[EMAIL PROTECTED]> writes:
> CVS m4 wants to use $(pkglibexecdir) defined as
> $(libexecdir)/$(PACKAGE) as the location of its installed but
> unversioned libtool modules. Any chance we can add that to the
> configmake module? Is it worth pushing for $(pkglibexecdir)
> upstream in au
Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> To get coreutils 6.1 to build on Tru64 Unix, in addition to the minor
> typo reported earlier, I had to change the prototype used for
> getnameinfo() to match the on in /usr/include/netdb.h
> The problem was that the selected prototype used siz
Paul Eggert CS.UCLA.EDU> writes:
>
> For Bison, I installed the following to add support for
> Automake-supplied variables to configmake.
>
> 2006-09-15 Paul Eggert cs.ucla.edu>
>
> * modules/configmake (Makefile.am): Add support for the
> Automake-supplied PKGLIBDIR, PKGINCLUDE
Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> While building coreutils v6.1 on Tru64 Unix, I found a minor typo
> breaking the build. Here is a patch to fix it.
Thanks; I installed that patch into gnulib.
> diff -ur src-6.1/lib/getaddrinfo.c src-6.1-local/lib/getaddrinfo.c
> --- src-6.1/lib
"Mark D. Baushke" <[EMAIL PROTECTED]> writes:
> * inttypes.m4 (gl_cv_header_working_stdint_h): Avoid
> 'test: =: unary operator expected' on Solaris 9.
> (gl_cv_header_inttypes_h): Be consistent in quoting.
Thanks, I installed that.
Bruno Haible <[EMAIL PROTECTED]> writes:
> * modules/javaversion (Makefile.am): Remove DEFS setting.
> (Depends-on): Add configmake, for PKGDATADIR definition.
Thanks. Don't you also need to add an #include "configmake.h" line to
lib/javaversion.c?
I installed this:
2006-09-18 Paul Eggert <[EMAIL PROTECTED]>
* gnulib-tool (avoidlist): Fix typo that broke options like
--avoid=lock that are used by coreutils bootstrap.
--- gnulib-tool.~1.166.~2006-09-18 08:50:05.0 -0700
+++ gnulib-tool 2006-09-18 10:03:47.00
It appears to be possible that
gl_cvs_header_working_stdint_h may not be set when
the inttypes.m4 generated tests are run. It is
probably a good idea to just quote the variable
arguments to test in this case to ensure that the
'=' operator is used in a binary operator context.
Thanks,
Ralf Wildenhues wrote:
> Hmm, ok. But traditional shells execute this construct
> while read foo
> do
> $whatever
> done <$file
>
> in a subshell, too, for example Solaris 10 sh.
Ouch. Looking at the variables, it indeed behaves like a subshell.
Looking at the process id, it does not..
Bruce Korb wrote:
> txtmi->txt_data = mmap (NULL, txtmi->txt_size, prot, flags, txtmi->txt_fd,
> 0);
...
> /*
> * Still here? We have to append a page of NUL's
> */
> txtmi->txt_full_size += pgsz;
> {
> void* pNuls;
>
> #ifdef MAP_ANONYMOUS
> pNuls = mmap ((v
Thanks for the suggestion. I broke the lines now, before the binary
operators (like the GNU standards recommends for C).
Bruno
Hello Bruno,
* Bruno Haible wrote on Mon, Sep 18, 2006 at 02:50:40PM CEST:
> I'm applying them all, with minor tweaks regarding the whitespace placement
> (break lines before a binary operator, not after it) and double-quotes
> (put double-quotes even where they are not strictly necessary, but wou
For some time now, getloadavg is a module that causes gnulib-tool to fail:
$ ./gnulib-tool --create-testdir --dir=/dev/shm/testdir getloadavg
...
checking for error_at_line... yes
configure: error: ././getloadavg.c is missing
make: Nothing to be done for `built_sources'.
make: *** No r
Ralf Wildenhues wrote:
> PPS: should the number of files used by a project exceed a few hundred,
> it may make sense to exploit bash3's `+=' with a func_append, in order
> to avoid the quadratic scaling associated with string enlargement:
Here's the patch I committed.
2006-09-17 Bruno Haible <[
Paul Eggert wrote:
> The javaversion module can now be simplified a bit, by adding a
> dependency on configmake, so that its 'make' output is made a bit
> shorter.
Yes. I'm doing this change.
2006-09-17 Bruno Haible <[EMAIL PROTECTED]>
* modules/javaversion (Makefile.am): Remove DEFS s
Ralf Wildenhues wrote:
> For some invocations, gnulib-tool is rather slow[1], which impacts
> productivity a bit. The following tries to improve things without
> sacrificing portability, while hopefully it doesn't compromise
> readability. ;-)
Thanks a lot for the patches! They indeed boost perf
I agree that this is a bug, and I'm interested in fixing this, but I
have little free time right now.
I'd prefer that --wrap can be used to indicate at what position the
tool should expect CR/LF on decoding. If there isn't a CR/LF at that
position, it should abort.
Also, there should be one new
[EMAIL PROTECTED] (Karl Berry) writes:
> rms said fine, so I installed the patches to the license Texinfo files
> (slightly tweaked) in both gnulib and the (purported) original location,
> gnu.org/licenses.
Thanks for talking to RMS and fixing this!
Comparing what was install in gnulib with the
24 matches
Mail list logo