* Bruno Haible wrote on Mon, Nov 13, 2006 at 08:59:49PM CET:
> Ralf Wildenhues wrote:
>
> > You could simplify this further:
> > - header files can go into *_SOURCES variables since about a decade now,
> > - EXTRA_*_SOURCES are already distributed.
> >
> > That means you can drop most EXTRA_DIST
Bruno Haible <[EMAIL PROTECTED]> writes:
> If you want to force it to a certain value, I think we can consider a
> --enable/--disable-inlining configure option.
Probably not worth the trouble. I can always configure with CC='gcc
-fno-inline'.
> How would you deal with such a link error situatio
On Fri, 2006-09-15 at 05:35 -0600, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Yoann Vandoorselaere on 9/15/2006 5:29 AM:
> > Hi,
> >
> > The c-ctype, c-strcase, c-strcasestr and c-strstr modules seem only to
> > implement their replacement functions using
Then your function body isn't "dirtied" with #if directives,
True, but system.h is :). In this case, I think I'll go for the
#if ENABLE_NLS, not so much because of the potential for warnings, but
because it is two lines of directives vs. six.
Thanks,
karl
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
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'
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
Bruno Haible <[EMAIL PROTECTED]> writes:
> AC_C_INLINE and gl_INLINE simply answer two different questions.
A problem I have with gl_INLINE is that it decides the value
HAVE_INLINE once, at configure-time. If I compile most of my package
with optimization, but then recompile some modules without
Jim Meyering wrote:
> It is inaccurate and uncharitable to call that automake work
> short-sighted. The problem is that development on that front seems to
> have stalled. Since that part of automake is incomplete, if you don't
> know the history, I can see how you would think it short-sighted.
O
Bruno Haible <[EMAIL PROTECTED]> writes:
> gnulib's lib directory now has over 600 source files. Only Paul and I have
> an overview of what's in gnulib;
Hold on a second; you inadvertently omitted Jim Meyering's name here.
Jim has contributed a ton of source code to gnulib over the years. He
kno
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
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> It sounds like the recent trend to remove uses of AC_LIBSOURCE
>> (in favor of listing source file names in each module-file Files: section)
>> is the reason for at least some of my missing dependencies.
>
> The removal of AC_LIBSOURC
Paul Eggert wrote:
Matthew Woehlke <[EMAIL PROTECTED]> writes:
I'm quite certain I remember it bombing (there are 'unsigned long
long's sprinkled in there without it). But I am guessing the problem
is just that CVS is a little off of coreutils-6.4, which is what I was
trying to patch. I think t
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]>
>
> *
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 <[EMAIL
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 variable.
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 "ln -s".
*** gnulib
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 subdirectories, set
Jim Meyering wrote:
> It sounds like the recent trend to remove uses of AC_LIBSOURCE
> (in favor of listing source file names in each module-file Files: section)
> is the reason for at least some of my missing dependencies.
The removal of AC_LIBSOURCE was indeed a major change - for the better
(mo
Hello Ralf,
> FWIW, I really haven't understood what the subdir-objects case is useful
> for in this context: gllib currently has a flat directory structure.
> Is it just for convenience or is there a necessity behind it?
gnulib's lib directory now has over 600 source files. Only Paul and I have
20 matches
Mail list logo
