With this patch, gnulib-tool supports source files in subdirectories of lib/.
2006-11-12 Bruno Haible <[EMAIL PROTECTED]>
Finish support for source files in subdirectories.
* gnulib-tool (func_emit_lib_Makefile_am): If some of the source files
are in subdirectorie
The --symlink option did not put the right links in place when --local-dir
was specified as a relative directory.
2006-11-12 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_ln): New function.
(func_ln_if_changed, func_create_testdir): Use it instead of
This adds an option --local-symlink that allows to have symlinks inside a
package but avoids symlinks to outside a package.
2006-11-12 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool: New option --local-symlink.
(func_usage): Document it.
(lsymbolic): New va
So far, gnulib-tool replaces build-aux with $auxdir in the configure.ac
snippet but not in the Makefile.am snippet. And there is - unless the
standard automake $(top_srcdir) - no standard $(auxdir) or similar that
could be used from any Makefile.am. This fixes it.
2006-11-12 Bruno Haible
Eric Blake wrote:
> gl_oset_search_atleast is documented as returning the found element.
> GL_ARRAY_OSET did this, but GL_AVLTREE_OSET and GL_RBTREE_OSET instead
> were mistakenly returning the node containing the element. OK to apply?
>
> 2006-11-12 Eric Blake <[EMAIL PROTECTED]>
>
> *
Eric Blake wrote:
> Is it worth trying to override AC_C_INLINE's definition of inline when we
> detect that inline is not supported, such that inline is redefined to the
> empty string, and uses of inline in headers that are not protected by
> HAVE_INLINE will then cause multiple copy link errors i
de gnulib in the same library, I
think gnulib-tool should support this.
3 among the 4 errors go away with the following gnulib-tool patch.
2006-11-13 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_emit_initmacro_start): Also override AC_LIBSOURCES.
(func_emit_initma
Ralf Wildenhues wrote:
> Speaking of short-sighted is a bit stretched
That word is withdrawn.
> with some functionality that basically serves for more than half a decade.
The functionality that can be triggered through Makefile.am variables is
indeed well designed and rock solid. Kudos especiall
Paul Eggert wrote:
> Jim has contributed a ton of source code to gnulib over the years. He
> knows gnulib just as well as I do -- maybe better -- and his efforts
> have been essential to gnulib's success.
Absolutely. I never intended to dispute Jim's merits. gnulib wouldn't be
gnulib without Jim'
Paul Eggert wrote:
> A downside of this approach is that if I compile the xalloc module
> with optimization (so that it does not bother to to generate a extern
> xmalloc function, but simply assumes it's inline) but then compile an
> xalloc user without optimization (so that it assumes there's an e
cking for error_at_line... yes
> | configure: error: ./gltests/getloadavg.c is missing
> | configure: error: ./configure failed for gltests
OK, I'm applying this fix. Your patch was half right.
2006-11-13 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_create_test
Paul Eggert wrote:
> whenever you get into trouble, just do "make clean"
> and then make with the CFLAGS you prefer.
Many hackers probably use the same approach... Since "make CFLAGS=..." does
not pass the CFLAGS down to subdirectories, the user of a package with
- its main sources in the main d
This adds support for libraries with dots in their name (seen frequently
in GNOME libraries).
2006-11-12 Bruno Haible <[EMAIL PROTECTED]>
* m4/lib-link.m4: Require at least autoconf-2.54.
(AC_LIB_LINKFLAGS_BODY) [autoconf < 2.61]: Turn dots into the library
local, INC${NAME} might come out empty, giving no
information about $prefix.)
2006-11-12 Bruno Haible <[EMAIL PROTECTED]>
* m4/lib-link.m4 (AC_LIB_LINKFLAGS, AC_LIB_HAVE_LINKFLAGS,
AC_LIB_LINKFLAGS_BODY): Also set a LIB${NAME}_PREFIX variable. Needed
for GNOME lib
Yoann Vandoorselaere wrote:
> Solaris 9 apparently lack the strcasestr() function.
If the program needs strcasestr(), then it needs the 'strcasestr' module.
It defines a replacement for strcasestr().
> Might we modify the
> c-strcasestr module so that it provide a replacement for platform
> lack
Yoann Vandoorselaere wrote:
> "However, if we have a platform missing strcasestr, then using
> c_strcasestr as the substitute implementation is probably okay, because
> that platform would probably be broken in other areas, such as locale
> support, ...
Solaris 9 and Solaris 10 (which also doesn't
Yoann Vandoorselaere wrote:
> > I don't think Chinese users will find it nice if you exclude them from
> > correct functioning of your program because of "performance" or "library
> > size".
>
> I don't think you are qualified to decide in place of the application
> developer whether the applicat
c-ctype 14 Nov 2006 11:07:32 -
***
*** 17,23
"c-ctype.h"
License:
! GPL
Maintainer:
Bruno Haible
--- 17,23
"c-ctype.h"
License:
! LGPL
Maintainer:
Bruno Haible
> As new dependencies get introduced to existing GnuLib
Hello Ralf,
> The patch below shaves a couple of minutes off of MODULES.html.sh's
> roughly 5 minutes worth of execution time. Half of that is achieved
> by not calling gnulib-tool more often than necessary, the other by
> eliminating a couple of quadratic file list handlings.
These are good tr
Ralf Wildenhues wrote:
> 2006-11-14 Ralf Wildenhues <[EMAIL PROTECTED]>
>
> * m4/inttypes.m4 (gl_INTTYPES_H): Use AC_CACHE_CHECK so that the
> test for conforming inttypes.h is both announced and cached.
Looks good to me. Thanks!
Bruno
Ralf Wildenhues wrote:
> I did that, but IMHO it's a bit inconsistent:
> $ echo 2> &1
> | bash: syntax error near unexpected token `&'
'>&' is an operator on its own, and '2>&1' is an idiom that doesn't require
spaces to be understandable.
Bruno
ble), turned the fatal error into a warning, and added comments:
2006-11-15 Yoann Vandoorselaere <[EMAIL PROTECTED]>
Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_create_testdir): Add license consistency check.
*** gnulib-tool 14 Nov 2006 09:37:20 -
Eric Blake wrote:
> 2006-11-15 Eric Blake <[EMAIL PROTECTED]>
>
> * m4/allocsa.m4 (gl_ALLOCSA): Don't invoke macro already picked
> up by the module dependency.
>
> Index: m4/allocsa.m4
> ===
> RCS file: /sources/gnulib
is not right. It's more or
less the opposite: "whether alloca can be implemented through a compiler
built-in" or similar.
I applied this.
2006-11-15 Bruno Haible <[EMAIL PROTECTED]>
* m4/alloca.m4 (gl_FUNC_ALLOCA): Fix the AC_CACHE_CHECK message.
*** m4/alloca.m4
Ralf Wildenhues wrote:
> The allocsa.m4 change contradicts
> http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00279.html
The URL is very relevant (I was tempted to use AC_REQUIRE, nearly falling
into the pitfall again), thanks. But I don't actually see the contradiction.
Bruno
Karl Berry wrote:
> gnulib-tool says you "may" need to include:
> #include
> #include
> #include
> #include "__fpending.h"
> #include "close-stream.h"
> #include "closeout.h"
> #include "error.h"
> #include "exit.h"
> #include "exitfail.h"
> #include "gettext.h"
> #include
Paul Eggert wrote:
> I should have also said: I changed it to LGPL.
Thanks. The remaining warnings from "gnulib-tool --create-testdir" are:
module argp depends on a module with an incompatible license: dirname
module argp depends on a module with an incompatible license: exit
module argp depends
Matthew,
Paul Eggert wrote:
> Eric Blake <[EMAIL PROTECTED]> writes:
>
> > I didn't see this show up on bug-gnulib, nor in the list queue, so I took
> > the liberty of resending it...
> >
> > Original Message
> > Date: Wed, 15 Nov 2006 19:13:36 -0600
> > From: Matthew Woehlke
>
Robinson Mittmann wrote:
> Looking at the "kernel_sinl" function in "sincosl.c" file I found that
> the limit value for choosing the computation method is wrong with
> respect of the remaining code:
>
> kernel_sinl (long double x, long double y, int iy)
> {
> ...
> if (x < 0.148375L)
> > Do you have a comparison of git with mercurial, monotone, bzr?
Reading the wikipedia articles on each of them
http://en.wikipedia.org/wiki/Git_(software)
http://en.wikipedia.org/wiki/Mercurial_(software)
http://en.wikipedia.org/wiki/Monotone_(software)
http://en.wikipedia.org/wiki/
Hello Sylvain,
Can you please tell: Are the git repositories visible in
http://git.sv.gnu.org/gitweb/
stored on a disk that is regularly backed up? If so, with which frequency
(daily, weekly, monthly)?
I'm asking because we are considering moving gnulib to this area as well.
Bruno
[EMAIL PROTECTED] wrote:
> It'd be a blank slate for me, learning git from ground up.
There are two tutorials for people with a CVS background:
http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
http://git.or.cz/course/cvs.html
> How well/easily would git sessions work thru fi
Karl Berry wrote:
> As I understand it, the reason for the proposal is because branches are
> supported better in git. But isn't wanting to make branches tantamount
> to making releases?
The reasons to make branches are:
1) for temporary small changes, testing etc.,
2) for adding features tha
Hi Paul,
> --- lib/regex.h 10 Aug 2006 20:08:01 - 1.38
> +++ lib/regex.h 27 Nov 2006 07:15:02 -
> @@ -635,14 +635,17 @@
> # endif
> # endif
> #endif
> -/* gcc 3.1 and up support the [restrict] syntax. */
> -#ifndef __restrict_arr
> -# if (__GNUC__ > 3 || (__GNUC__ ==
Some gnulib modules may want to augment noinst_LTLIBRARIES, so gnulib-tool
needs to initialize it.
2006-11-26 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_emit_lib_Makefile_am): Initialize also
noinst_LTLIBRARIES.
*** gnulib-tool.bak 2006-11-21 02:59:27.000
.
Opinions?
2006-11-21 Bruno Haible <[EMAIL PROTECTED]>
* m4/eoverflow.m4 (gl_EOVERFLOW): Use AC_COMPUTE_INT instead of
_AC_COMPUTE_INT.
(AC_COMPUTE_INT): Add fallback definition for autoconf < 2.61.
* m4/ptrdiff_max.m4 (gl_PTRDIFF_MAX): Use AC_COMPUTE_IN
to me:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29994
Until they document it properly, I prefer to ignore this case.
Bruno
2006-11-27 Paul Eggert <[EMAIL PROTECTED]>
Bruno Haible <[EMAIL PROTECTED]>
* lib/gettext.h (_LIBGETTEXT_HAVE_VARIABLE
FYI: This bug is now fixed not only in gnulib, but also in gettext-0.16.1.
> 2006-11-20 Bruno Haible <[EMAIL PROTECTED]>
>
> * gettext.m4 (AM_GNU_GETTEXT): Revert 2005-07-28 patch: Use
> changequote instead of pairs of brackets.
> Reported by Andreas Schwab <[EMAIL PROTECTED]>.
Ben Pfaff wrote:
> C99 added some useful functions to math.h, such as trunc and
> round. Would there be objections to a module that adds
> implementations of those functions?
This would be a good idea. Can you write it so that it augments ,
like we do for or ?
If you're at it, you can also cont
James Youngman wrote:
> I am using gettext version 0.14.6. Its version of po/Makefile.in.in
> uses @MKINSTALLDIRS@, but the m4 files in current gnulib do not
> substitute that variable. This means that the generated po/Makefile
> contains a naked @[EMAIL PROTECTED]
>
> I think that's an incompa
Simon Josefsson wrote:
> automake 1.10 and gettext 0.15 for some time more, because that
> is what is installed on my up-to-date Debian 'unstable' box.
Ouch. automake 1.10 and gettext 0.15 don't work together. I'll talk with
the Debian guys about it. Thanks for the warning!
Bruno
Paul Eggert wrote:
> Thanks, I like this change. I tested it for m4/stdint.m4, and
> installed that part of the change.
OK, so I installed the rest.
> Would you mind if we removed m4/ptrdiff_max.m4? Nobody has used it
> since 2003-11-12, as far as I know. stdint obsoletes it now, anyway.
Done
James Youngman wrote:
> OK. Is po/Makefile.in.in in gettext? If not, do I need to obtain
> gettext from CVS as well?
po/Makefile.in.in is installed when you run gettextize. You shouldn't use
the gettext CVS regularly, except if you're specially keen on new gettext
features.
> > It's known, an
Simon Josefsson wrote:
> The patch below causes this error when running configure for me:
>
> checking absolute name of ... ///usr/include/stdint.h
> checking whether stdint.h conforms to C99... no
> ./configure: line 31250: syntax error near unexpected token `('
> ./configure: line 31250: `if { a
modules to augment noinst_LTLIBRARIES. (For example, if a
package wants to be buildable with CC=g++ but needs the regex module, it
needs to add "-x c" to the CPPFLAGS of this module. Automake supports only
CPPFLAGS per library, not per module, so this requires an intermediate
library.)
Matthew Woehlke wrote:
> I also noticed that although there is a HAVE_FCHDIR (properly set in
> config.h), it is not being used.
>
> How needed are the *at functions? Can I rip them out? Can I emulate
> fchdir()? Is there some other way to achieve what fchdir() is being used
> for?
Emulating f
Eric Blake wrote:
> Also, GNU coding
> standards recommend using just 'name', rather than 'filename' or even 'file'.
Huh? I think there is a misunderstanding. The GNU standards don't want
'pathname' to occur in the documentation in the sense as POSIX uses it,
because of the PATH variable and the
Eric Blake wrote:
> > What about the FD table; should it be a hash table, a binary tree, an
> > ordered linked list, or something else entirely?
>
> Gnulib already provides the gl_list module. The idea there is that you start
> by coding with an array list (probably a good choice anyways, since
Karl Berry wrote:
>gnulib-tool
>
> That's for Bruno, I expect.
I abstain. The keyword has served its purpose once, by allowing us to easily
diagnose that
a user's gnulib checkout was 6 months old. But OTOH I believe, with Jim, that
git's nonlinear
branch topology makes this unusable in the f
Karl Berry wrote on 2006-11-15:
> Would it be reasonable/possible to have gnulib-tool output only the
> top-level #includes?
Implemented. Thanks for bringing this up.
2006-12-10 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_import): Show the include files on
= modules/no-c++ ===
Description:
Support for compiling in C mode when CC is set to a C++ compiler.
Files:
m4/no-c++.m4
Depends-on:
configure.ac:
gt_NO_CXX
Makefile.am:
Include:
License:
LGPL
Maintainer:
Bruno Haible
===
Lorenzo Bettini wrote:
> I've just started using gnulib, and I have a doubt.
> I've imported strdup and I'm using it in a C++ program.
>
> Now should I import strdup.h in the C++ program simply like this
>
> #include "strdup.h"
>
> Or should I wrap it as follows?
>
> extern "C" {
> #include "st
Ralf Wildenhues wrote:
> > ! for module in `join "$tmp"/modules1 "$tmp"/modules2`; do
>
> I'm pretty sure you want `LC_ALL=C join' instead here.
Yes. Good catch. Thanks.
--- gnulib-tool 11 Dec 2006 12:41:09 - 1.200
+++ gnulib-tool 11 Dec 2006 18:19:59 - 1.201
@@ -2189,7 +2189
Paul Eggert wrote:
> for it to be useful won't we
> also need to sprinkle $(NO_CXX) throughout the descriptions of all
> modules that are not compilable with g++?
Yes. This is easy to do. I imagine Simon's buildbot will give us the list
of modules for which it is necessary.
So far, I put each suc
alloc -> str_cd_iconv (with reversed arguments)
Bruno
2006-12-12 Bruno Haible <[EMAIL PROTECTED]>
Merge these changes.
2006-09-05 Bruno Haible <[EMAIL PROTECTED]>
* lib/iconvme.c (iconv_string): No need to save and restore errno when
iconv_a
Lorenzo Bettini wrote:
> I tried it and got no problem, but as far as I understand this is not a
> proof, since
>
> #if defined HAVE_DECL_STRDUP && !HAVE_DECL_STRDUP && !defined strdup
> /* Duplicate S, returning an identical malloc'd string. */
> extern char *strdup (const char *s);
> #endif
>
Lorenzo Bettini wrote:
> I thus included a possible patch.
strdup.h is all you need? Ok, I commit this:
2006-12-19 Bruno Haible <[EMAIL PROTECTED]>
* lib/strdup.h [C++]: Wrap definitions in extern "C".
Suggested by Lorenzo Bettini <[EMAIL PROTECTE
Lorenzo Bettini wrote:
> as reported in the documentation, I have the source base and m4 base,
> resp., in gl and gl/m4
>
> now I'm trying to run gnulib-tool --update as follows, but I get an error:
>
> gnulib-tool --update --m4-base=gl/m4/ --source-base=gl/ --dry-run
> gnulib-tool: invalid opti
Paul Eggert wrote:
> Compiling everything with -fwrapv is simple. It has
> optimization drawbacks, but if that's the best we can do
> now, then we'll probably do it. And once we do it, human
> nature suggests that we will generally not bother with the
> painstaking analysis needed to omit -fwrapv
Lorenzo Bettini wrote:
> ~/work/gnulib/gnulib-tool --update --dry-run
> Module list with included dependencies:
>
> File list:
>lib/dummy.c
>m4/onceonly_2_57.m4
> Create directory ./lib
> Create directory ./m4
> Create directory ./lib
> Create directory ./m4
> Copy file lib/dummy.c
> Copy
Ralf Wildenhues wrote:
> > "gnulib-tool --update" relies on the presence of gnulib-comp.m4 and
> > gnulib-cache.m4.
>
> Which may be found only after knowing the value of $m4base, as that's
> where those files are.
There's a trick. Look at gnulib-tool lines 2780..2818.
Bruno
Lorenzo Bettini wrote:
> > Maybe: "gnulib-tool --update" relies on the presence of gnulib-comp.m4 and
> > gnulib-cache.m4.
> >
>
> OK, those files were not there (this is because gnulib-cache.m4 is not
> included in the .tar.gz produced by make dist, is this correct?)
>
> now --update works as
Lorenzo Bettini wrote:
> gnulib-tool says:
>
> You may need to add #include directives for the following .h files.
>#include
>
> shouldn't it be
>
>#include "getopt.h"
>
> ?
Given that the source and build directories are searched by the compiler
(due to the many "-I." flags), it boil
Lorenzo Bettini wrote:
> > You see, there's no clear borderline between <> and "".
>
> I see, but are <> ensuring that the version of gnulib is used (even if
> getopt.h is available in the system)?
The -I flags added by automake and gnulib-tool normally guarantee that.
Normally. I.e. not if the
XX
>
> Makefile.am:
>
> Include:
>
> License:
> LGPL
>
> Maintainer:
> Bruno Haible
Hi,
GNU sed version 4.1b is now implementing its --posix option correctly.
We can use this to avoid portability problems in gnulib-tool.
Please report any breakage that this change introduces :-)
2006-12-22 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (SED): New va
Paul Eggert wrote:
> Now that we have a wctype module we can simplify some of the other
> modules to just include and depend on the wctype module.
> Here is a proposed patch.
>
> 2006-12-21 Paul Eggert <[EMAIL PROTECTED]>
>
> * lib/mbchar.h: Just include ; the wctype module
> handl
s
printable. Let's whether someone on an old platform but with ISO-8859-1
characters in his filenames cares about it...
Bruno
*** lib/wctype_.h 22 Dec 2006 00:21:54 - 1.1
--- lib/wctype_.h 22 Dec 2006 16:19:33 -
***
*** 18,30
/* Written by Bruno
Paul Eggert wrote:
> 2006-12-21 Paul Eggert <[EMAIL PROTECTED]>
>
> * MODULES.html.sh: New module wctype.
> * lib/wctype_.h, m4/wctype.m4, modules/wctype: New files.
> * lib/fnmatch.c: Don't bother to include before
> , since the new wctype module should fix this.
>
Hi,
Can an ACL expert please proofread this? This adds ACL support to the
copy_file_preserving function. It compiles fine, but I cannot test it since
none of my systems has ACL support.
2006-12-22 Bruno Haible <[EMAIL PROTECTED]>
* lib/copy-file.c: Include
This fixes a build error on mingw, if you happen to use the sys_stat module
together with the canonicalize-lgpl module.
2006-12-23 Bruno Haible <[EMAIL PROTECTED]>
* lib/canonicalize-lgpl.c (__realpath): Test HAVE_READLINK instead of
S_ISLNK.
Needed because gn
Hi Jim,
For some complicated reasons (too long to explain here), gettext needs to
use safe-read.h with a C++ compiler on mingw and cygwin. Is this patch ok
with you?
2006-12-23 Bruno Haible <[EMAIL PROTECTED]>
* lib/safe-read.h [C++]: Wrap declarations in extern "C&qu
Eric Blake asked:
> Is it also necessary to wrap safe-read.c with extern "C", for use when
> using g++ as a type-safe variant of a C compiler, to match the header?
Normally not. The 'extern "C"' is only needed in mixed C/C++ builds.
> And should you be symmetric with safe-write.h?
I deal with th
Hi,
The --with-libxyz-prefix option did not actually work on OpenBSD. This patch
should fix it.
2006-12-24 Bruno Haible <[EMAIL PROTECTED]>
Improve support for OpenBSD.
* build-aux/config.rpath (libname_spec): Export.
(library_names_spec): New variable.
But I think that judicious use of
library dependencies can avoid most of the problems; and as a last resort,
the remaining problems can be solved by splitting the configure.ac file.
2007-01-01 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_emit_copyright_notice)
Hi,
Following the gnulib-tool change, we can remove the explicit definitions
of macro names. Paul, Jim: Objections?
2007-01-01 Bruno Haible <[EMAIL PROTECTED]>
* m4/close-stream.m4 (gl_CLOSE_STREAM): Remove GNULIB_CLOSE_STREAM
macro definition.
* m4/fcntl-sa
Hi Jim,
Now that gnulib-tool defines GNULIB_FTS when the fts module is in use, and
GNULIB_FTS_LGPL when the fts-lgpl module is in use, the _LGPL_PACKAGE macro
is redundant. Here is a proposed patch:
2007-01-01 Bruno Haible <[EMAIL PROTECTED]>
* m4/fts.m4 (gl_FUNC_FTS_LGPL):
Hi Simon,
Now that gnulib-tool defines GNULIB_* macros for every module in use, the
GC_USE_* macros are redundant. Here is a proposed patch.
2007-01-01 Bruno Haible <[EMAIL PROTECTED]>
* m4/gc-arcfour.m4 (gl_GC_ARCFOUR): Remove GC_USE_ARCFOUR macro
definition.
*
Hi Jim,
Now that gnulib-tool defines GNULIB_CANONICALIZE when the canonicalize module
is in use, the PROVIDE_CANONICALIZE_FILENAME_MODE macro is redundant. Here is
a proposed patch:
2007-01-01 Bruno Haible <[EMAIL PROTECTED]>
* m4/canonicalize.m4 (AC_FUNC_CANONICALIZE_FIL
The settime and nanosleep functions are declared in timespec.h; therefore
I think the module descriptions of the corresponding modules should reflect
this. How about this patch, Paul?
2007-01-01 Bruno Haible <[EMAIL PROTECTED]>
* modules/settime (Include): Require time
Hi Jim,
This looks like a typo. OK to fix?
2007-01-01 Bruno Haible <[EMAIL PROTECTED]>
* modules/lchmod (Include): Require lchmod.h, not lchown.h.
*** modules/lchmod.bak 2006-10-13 01:27:12.0 +0200
--- modules/lchmod 2007-01-01 17:00:42.0
have not included patches to gc.h and hmac.h, because I don't
understand these modules well enough.
2007-01-01 Bruno Haible <[EMAIL PROTECTED]>
* lib/timespec.h (nanosleep): Declare only if GNULIB_NANOSLEEP.
(gettime): Declare only if GNULIB_GETTIME.
(settim
Hi,
When I use the fchdir emulation on a Linux 2.4.x system (that doesn't have
openat() and similar), the coreutils-6.7 tests install/basic-1 and mkdir/p-3
fail. The reason is this part:
$ mkdir -p sub1/d
$ cd sub1/d
$ chmod a-rx ..
$ chmod a-r .
$ ginstall -d rel/a rel/b
ginstall: cannot create
e-lgpl', not 'canonicalize'.
Opinions?
If you want to test this with coreutils, you need to add fchdir to the
module list, use --avoid=canonicalize-lgpl, and drop the fchdir-stub.c.
2006-12-30 Bruno Haible <[EMAIL PROTECTED]>
* modules/fchdir: New file.
Hi,
Since 2000 the need for elementary functions on Unicode strings has been
apparent and increasing:
- some utility functions exist in GNOME's glib,
- clisp, gettext, emacs, python, ... need a programmatic access to the
character name tables,
- gettext's linebreak module relies on sever
Paul Eggert wrote:
> The recent 'sed --posix' change leaked into Makefiles, which broke
> coreutils on Solaris. Rather than fix the problem one instance of
> $SED at a time, I took a different tack by undoing the change and
> installing the following less-intrusive change instead.
Thanks and sorr
> Seems to have fixed several of the modules I mentioned, although the
> builder is still working on some remaining ones. Thanks!
One failure is still there, at
http://autobuild.josefsson.org/gnulib/log-200701021304717357000.txt
In file included from ../../gllib/fts.c:54:
../../gllib/fts_.h:68:
Paul Eggert wrote:
> Is there any rule for whether the Include: sections' lines should
> start with '#include'?
So far the '#include ' is optional. I made it optional because it'd be so much
useless typing work and redundant to read otherwise.
> I noticed 34 instances with #include and 276 withou
Simon Josefsson wrote:
> > unicasecase folding
>
> Is this NFKC?
I didn't consider normalization functions so far, on the premise that text
being exchanged between applications is assumed to be precomposed.
But their presence in Java APIs and the IDN case shows that APIs for
composing and de
Eric Blake wrote:
> Is there any reason that using the clean-temp module does not AC_REQUIRE
> ([AC_SYS_LARGEFILE]) in the configure script? Without that, it is possible
> on some hosts that temporary files are artificially capped at 2GiB, even
> though enabling largefile support could make things
Paul Eggert wrote:
> I'm a bit dubious about this one, as it adds to the .h maintenance
> burden and I'm not sure the benefit is worth the cost.
> ...
> The other parts I'm ambivalent about.
So let's drop the idea. I was hesitating too.
> For the special case of nanosleep, one might want nanoslee
Simon Josefsson wrote:
> I know gnulib never promised to provide code that worked without the
> gnulib-tool machinery, but previously the tweaks to make that work
> anyway was small. Now they are larger. Before, you'd typically only
> have to copy the source code and the M4 files, and arrange for
Eric Blake writes:
> > In the presence of multiple gnulib-tool invocations from the same directory
> > with the same configure.ac file, such macros may indicate the wrong thing
> > (because if you build libgnuA.a and libgnuB.a, the module may be compiled
> > into libgnuA but not into libgnuB). But
Simon Josefsson writes:
> Btw, does anyone know why --create-testdir runs ./configure + make
> distclean?
It does it when the gllib/ directory contains built sources. A possible and
worthy
optimization would be to do it only if it contains built sources that are not
listed
in MOSTLYCLEANFILES, C
Eric Blake asks:
> > Should we just make GL_EARLY always invoke AC_SYS_LARGEFILE, so
> > that any application that uses gnulib automatically also supports large
> > files?
Yes. The 32-bit off_t is nowadays only historical baggage. There is normally
no good reason to _not_ use AC_SYS_LARGEFILE. I'd
Eric Blake wrote:
> > The error function uses program_name, which is defined in the progname
> > module.
>
> Thanks for the patch; however, the current state of things in this area is
> intentional. error is LGPL, whereas progname is GPL. RMS does not want
> additional baggage accompanying the er
This patch simplifies the previous change.
2007-01-08 Bruno Haible <[EMAIL PROTECTED]>
* m4/lib-link.m4 (AC_LIB_LINKFLAGS_BODY): Simplify the sorting command.
--- m4/lib-link.m4 2 Jan 2007 20:53:28 - 1.18
+++ m4/lib-link.m4 8 Jan 2007 18:51:24 -
@@ -1,
Richard Kenner wrote:
> (3) How many programs are known to rely on wrap semantics? For each:
> (a) How hard was it to determine there was a problem with that
> assumption?
A piece of data for GNU clisp and cln:
- For clisp, it was easy to find out and fix all problems, because the
Following Simon's comments, I backed this out and instead introduce a
macro gl_MODULE_INDICATOR, for use in the module description.
2007-01-08 Bruno Haible <[EMAIL PROTECTED]>
* m4/gnulib-common.m4: New file.
* gnulib-tool (func_get_autoconf_snippet): Undo
Hello Jim,
> I'd rather defer this sort of change, since it introduces a hard
> dependency on gnulib-tool, with only marginal added value. With this
> sort of change, a project that uses this module without going through
> gnulib-tool will not work properly.
>
> If/once we all agree that it's ok
701 - 800 of 13795 matches
Mail list logo
