Ralf Wildenhues wrote:
> We could ask help2man to have it return a different exit
> status if it gets an exit status of 126 from the program, and have it
> return 63 then, which `missing' will interpret as version mismatch.
Uuhhh. I'm not sure you get a defined exit status when you try to execute
X
fields plus 'char f_fstypename[]', containing the filesystem name, and a few
minor fields that src/stat.c uses, and to transform the lib/fsusage.c code
into a gnu_statvfs function that could be used by both "df" and "stat".
Does this seem worthwhile? Can the SVR2 code (t
nk-follow, rmdir-errno, unlink-busy,
> winsz-ioctl, and winsz-termios into it.
> Add lchmod.
> Add top-level Misc section and put host-os, perl, and uptime
> into it.
I made this additional change.
2006-08-24 Bruno Haible <[EMAIL PROTECTED]>
*
ith a theoretical "problem". Hmm.
It's not theoretical. I invite you to install a cross-compiler and try it.
Here's a patch that is even simpler, touching only the configure.ac file.
2006-08-24 Bruno Haible <[EMAIL PROTECTED]>
* configure.ac: Set HELP2MAN to a
Karl Berry wrote:
> I'm not sure it's best to add that additional level of
> infrastructure/indirection to Hello.
Yes, if it can be done through the one-liner by Ralf and my other
configure.ac patch today, that is simpler.
> Also, why not adding the help2man to build-aux?
>
> Sounds good to
Ralf Wildenhues wrote:
> First, I think you wouldn't want `make' to keep trying to update
> hello.1
Well, if HELP2MAN is the command ':' that doesn't eat CPU time, it doesn't
matter.
> so a rule like
> if test '$(cross_compiling)' = yes
The value of $cross_compiling can also be 'maybe'. To be
Jim Meyering asks:
> I'm curious: what's your motivation for using it?
Portability testing. Through the BeOS porting, I found the following
problems not limited to BeOS:
- check-AUTHORS: applies to any platform that doesn't build all of the
programs.
- mbchar.h problem: applies to any plat
Hi,
I committed this change, to test non-default sourcebase and m4base.
Please let me know if it causes problems.
2006-08-24 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_create_testdir): Use non-default values of
sourcebase and m4base.
*** gnulib-20060823/gnuli
Karl Berry wrote:
> However, on MinGW all three tests fail because the program outputs CRLF
> line endings, while the test suite creates files with LF ending.
> (Not sure if you want to worry about this...)
>
> Not sure if I do either. What do other (real) programs do?
Some programs
Paul Eggert wrote:
> Currently, in-place builds for coreutils generte output that looks
> like this:
>
> gcc -std=gnu99 -DHAVE_CONFIG_H -DLIBDIR=\"/usr/local/lib\" -I. -I. -I.
> -g -O2 -c allocsa.c
> gcc -std=gnu99 -DHAVE_CONFIG_H -DLIBDIR=\"/usr/local/lib\" -I. -I. -I.
> -g -O2 -c bas
Ralf Wildenhues wrote:
> installing
> a library that contains some public symbols corresponding to gnulib
> modules, thus having generic names (and thus possibly conflicting with
> other libraries) seems to me unfortunate at best.
>
> So even if turns out to be necessary for libgettextlib to do so
Paul Eggert wrote:
> what is the
> recommended way to use AM_GNU_GETTEXT([external], ...), gnulib-tool,
> and autopoint/autoreconf ... autopoint brings in
> yet another (incompatible) copy of them.
Currently, there is a general problem: After a release is made, if users
do a "gnulib-tool --update"
Eric Blake wrote:
> Unfortunately, this is now giving me the following when bootstrapping m4:
>
> during gnulib-tool update:
> Updating file ltdl/m4/lock.m4 (backup in ltdl/m4/lock.m4~)
>
> during autoreconf -fv
> autoreconf: running: autopoint --force
> ...
> Copying file ltdl/m4/lock.m4
>
> ..
Ralf Wildenhues wrote:
> > I wouldn't mind if the specification were per source file:
> >
> > localcharset_c_CPPFLAGS = $(AM_CPPFLAGS) -DLIBDIR=\"$(libdir)\"
>
> That's a possibility, but it runs contrary of the notion of per-target
> flags. More than one object may be created from one source
Karl Berry wrote:
> Or produce output with CR/LF always,
>
> Really? That seems wrong to me for Hello (and just about any other
> program). Just running hello on a Unixish system shouldn't write a \r!
Not on Unix systems, of course. But on Woe32 systems, writing text with
CR/LF is the norm
Eric Blake wrote:
> Maybe it's time to teach autoreconf about gnulib-tool. Now that GNU hello
> uses gnulib-tool, it is becoming more and more the recommended GNU way of
> building a project. It would be nice if autoreconf 2.61 could
> automatically invoke gnulib-tool between autopoint and acloca
his instead?
>
> if (!(numer >= 0
> ? (result.rem >= 0
>&& (denom >= 0 ? result.rem < denom : - result.rem > denom))
> : (result.rem <= 0
>&& (denom >= 0 ? - result.rem &
Hi,
Paul Eggert noted that vasnprintf should be able to return strings of length
> INT_MAX. Here's a patch to that effect.
Yoann, is the vsnprintf.c patch OK with you? It corresponds to Paul's fixes
to snprintf.c a week ago.
2006-08-26 Bruno Haible <[EMAIL PROTECTED]>
Paul Eggert wrote:
> > But it's important to know that c_strstr (s, "x") is not safe and
> > c_strstr (s, "123") is also not safe. The programmer needs to have the
> > precise criteria.
>
> I don't quite follow this. c_strstr (S, "x") is safe in all cases; it
> never has undefined behavior. I
Eric Blake wrote:
> Paul's latest updates to module dependencies pulled in several .m4 files
> that trigger gcc compiler warnings, breaking the configuration of m4 with
> '-Werror' where it had previously been working. Paul, Bruno, are these
> okay to install?
I installed the remaining patch to c
right thing. Usually getaddrinfo is
> called with hints structure that is zeroed out, and only the relevant
> flags asserted. If family isn't asserted, it usually means "take any
> family".
I see. Then what about this patch? It compiles fine on BeOS.
2
This makes for a better error handling during "patch".
2006-08-26 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_verify_module): Check against misapplying patch.
*** gnulib-20060823/gnulib-tool 2006-08-24 03:52:14.0 +0200
--- gnulib-20060823-modi
ld not do
the right thing if it doesn't know about the local-dir. The patch below
should fix it.
Bruno
2006-08-26 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_relativize, func_relconcat): New functions.
Give an error if --local-dir is given with --update.
Mostly comment updates.
2006-08-27 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_get_tests_module): Don't assume that $gnulib_dir
is the current directory. Respect also $local_gnulib_dir.
*** gnulib-20060823/gnulib-tool 2006-08-27 01:48:40.0 +0200
Makefile.am to some
other name and include it from the real Makefile.am.
This patch adds an option --makefile-name that does this.
2006-08-27 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool: New option --makefile-name.
(func_emit_lib_Makefile_am, func_emit_tests_Makefile_am
Paul Eggert wrote:
> 2006-08-23 Paul Eggert <[EMAIL PROTECTED]>
>
> * src/stat.c (HAVE_STRUCT_STATXFS_F_FSID___VAL): Define. This
> macro was being used without being defined.
Compiling the current coreutils CVS on MacOS X 10.3.9 now gives this error:
stat.c: In function `print_st
Simon Josefsson wrote:
> > This patch adds an option --makefile-name that does this.
>
> I mentioned that approach earlier in:
>
> http://article.gmane.org/gmane.comp.lib.gnulib.bugs/1969
Sorry, I missed or forgot that.
> The problem in automake that would had to be fixed was this:
>
> http://
Yoann Vandoorselaere wrote:
> Look good to me.
OK, the patch has been applied.
Bruno
Eric Blake wrote:
> Committing this obvious fix:
>
> 2006-08-28 Eric Blake <[EMAIL PROTECTED]>
>
> * modules/inttypes (Depends-on): Fix sed error when inttypes.h
> needs wrapper.
Thanks. Of course.
Bruno
Eric Blake wrote:
> Cygwin is currently failing the inttypes check because it does not provide
> SCNX8, among others. POSIX does not require the existence of SCNX*, so
> cygwin
> does not provide them.
Oops. I missed the fact that the PRI* and SCN* macros are not symmetric.
SCNX* makes no sens
Eric Blake wrote:
> One more issue - when the replacement is needed,
> inttypes-pri.m4 AC_SUBST's PRI_MACROS_BROKEN as the empty string when they
> work, rather than defining it to 0; which resulted in lots of preprocessor
> compilation errors:
>
> make[2]: Entering directory `/home/eblake/tar/
Paul Eggert wrote:
> 2006-08-25 Paul Eggert <[EMAIL PROTECTED]>
>
> New configmake module, so that "make" output needn't be cluttered
> by fluff like '-DLIBDIR=\"/usr/local/lib\"'.
> * modules/configmake: New file.
IMO it would be useful to add comments that tell:
- Why does
Paul Eggert wrote:
> Bootstrapping coreutils found one minor glitch: inttypes now relies on
> gl_HEADER_INTTYPES_H indirectly via gt_INTTYPES_PRI but doesn't list
> the file containing it.
Thanks for noticing it! It was certainly not intended. I'll clean it up.
> While we're on the subject we sho
Paul Eggert wrote:
> It seems a bit cleaner to me to have
> the inttypes module be the only module that needs to figure out
> the absolute name of .
Maybe a bit cleaner, but also a little more complex... But I don't mind.
Both codes look equally safe.
Bruno
Paul Eggert wrote:
> what is the
> recommended way to use AM_GNU_GETTEXT([external], ...), gnulib-tool,
> and autopoint/autoreconf in such a way that you don't get the
> following files into your m4 directory afterwards?
>
>glibc2.m4 intdiv0.m4 inttypes-h.m4 inttypes-pri.m4 lcmessage.m4
>l
> + echo '#define LIBDIR "$(libdir)"'; \
Thanks. I now did this change.
2006-08-29 Bruno Haible <[EMAIL PROTECTED]>
* modules/localcharset (Depends-on): Add configmake.
(Makefile.am): Remove setting of LIBDIR through DEFS.
Ralf Wildenhues wrote:
> > > Question to the autoconf experts: Is it possible to write a macro
> > > AM_GETTEXT_NEED_NGETTEXT such that whenever a user writes
> > >AM_GETTEXT_NEED_NGETTEXT
> > >AM_GNU_GETTEXT
> > > or
> > >AM_GNU_GETTEXT
> > >AM_GETTEXT_NEED_NGETTEXT
> > > the AM_GN
u meant. Your patch would be ok to
apply after converting tabs to spaces [hint for your .emacs:
;; Tabs are anachronistic.
(setq-default indent-tabs-mode nil)
], but I hope the following is a little more maintainable:
2006-08-31 Bruno Haible <[EMAIL PROTECTED]>
* gnu
ial definitions for EXTRA_DIST, MOSTLYCLEANFILES etc.
themselves. This is a little more manual work, but allows the generated
gnulib.mk to be fully incremental. One might consider to write out
the set of empty variable assignments to a separate file, but for the
moment I'd consider such a fea
Eric Blake wrote:
> Rather than making me globally
> change my style, would you accept this patch so that gnulib-tool will stay
> with your style, regardless of emacs whitespace-mode?
Yes. Thanks!
Bruno
Hello,
Davide Angelocola wrote:
> this module defines three functions:
> chomp() strip leading whitespaces
> chug() strip trailing whitespaces
> strip() strip trailing and leading whitespaces
Thanks for the proposal. I think this functionality would be useful
in gnulib, but it needs a bit of pol
(but less portable),
also teaches me to not use too "tricky" constructs.
2006-08-31 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (nl): Remove variable.
(sed_transform_lib_file): Use more robust test for config-h module.
(func_import): Fix typo in 2006
thout fchdir() probably don't have a /proc filesystem anyway...
2006-08-19 Bruno Haible <[EMAIL PROTECTED]>
* lib/fts.c (fts_open): If fchdir() does not exist, set FTS_NOCHDIR
and unset FTS_CWDFD.
(fts_stat): If fchdir() does not exist, use lstat instead of f
Hi Davide,
[Re-added bug-gnulib to the CCs.]
Davide Angelocola wrote:
> On Thursday 31 August 2006 22:41, you wrote:
> > Thanks for the proposal. I think this functionality would be useful
> > in gnulib, but it needs a bit of polishing before your code can be
> > included:
> >
> > - The pretty st
Paul Eggert wrote:
> Both of these modules should simply be migrated into Gnulib;
> they don't really belong in Autoconf.
I agree. Thanks!
Bruno
Paul Eggert wrote:
> The recent flurry of --makefile-name patches broke coreutils bootstrap
> (which hasn't yet been converted to use --makefile-name)
You're right, of course. Sorry. I observed the same automake errors,
but thought they were due to coreutils _already_ using --makefile-name...
Bru
[Re-added bug-gnulib in CC.]
Davide Angelocola wrote:
> On Friday 01 September 2006 15:01, you wrote:
> > About the function names: 'chug' and 'chomp' are not self-documenting
> > function names either. I'd propose trim_trailing and trim_leading.
> > (The Lisp name string-left-trim and string-righ
Paul Eggert wrote:
> On platforms lacking fchdir,
> put a wrapper around 'open' so that we can keep track of which file
> descriptors correspond to directories. The 'open' wrapper puts the
> name of the opened directory into a hash table. (The name must be
> absolute, so 'open' may need to do the
Eric Blake wrote:
> Should we have a gnulib module for *printf that allows us to use the
> POSIX-mandated printf("%zu", (size_t)1) modifier for size_t variables? Or
> what is the current recommended practice for printing size_t?
libintl has a POSIX compliant printf, declared in , for platforms
wh
Hi,
This change is needed so that the detection of shared libraries works on the
mingw platform.
2006-09-03 Bruno Haible <[EMAIL PROTECTED]>
* lib-link.m4 (AC_LIB_LINKFLAGS_BODY): Locate mingw shared libraries
correctly.
diff -r -c3 gettext-0.15/autoconf-lib-link/
Hello Davide,
The first loop looks fine, safe for multibyte locales. But in the second loop:
> > In multibyte strings you cannot "go backwards". You have to write the
> > algorithm in a way that progresses from the first to the last multibyte
> > character. (*) In this case, you can do so by movi
Hi Simon,
I'm trying to unify your 'iconvme' module and my 'iconvstring' module (from
GNU gettext).
extern char *iconv_string (const char *string, const char *from_code,
const char *to_code);
extern char *iconv_alloc (iconv_t cd, const char *string);
vs.
exter
Oskar Liljeblad wrote:
> it would however be very useful if these functions would
> null-terminate the generated strings properly as well. I assume str_iconv
> and str_cd_iconv would add a single null-byte
Yes. the str_* functions expect a C string as input and produce one as
output, i.e. the from
[Re-added bug-gnulib in CC.]
Hello Davide,
Thanks for the new code. Looks quite good now. The second loop, however,
will crash when passed a string consisting entirely of whitespace.
I see also you've partially adopted the GNU style for this code. Fine!
Indeed, before we put code into gnulib, we
Simon Josefsson wrote:
> --- gpl.texi 16 Jun 2006 17:35:17 +0200 1.4
> +++ gpl.texi 04 Sep 2006 17:39:43 +0200
> @@ -1,5 +1,5 @@
> @node Copying
> [EMAIL PROTECTED] GNU GENERAL PUBLIC LICENSE
> [EMAIL PROTECTED] GNU General Public License
> @center Version 2, June 1991
>
> @c This
Furthermore lgpl.texi creates an entry in the index, but gpl.texi doesn't.
Also when you have a package partially under GPL, partially under LGPL,
and partially under FDL, the title "Copying" of gpl.texi makes no sense
any more. The other title "Library Copying" is nonsense as well, since
RMS does
Simon,
> I believe the patch below contains all changes mentioned so far.
> Bruno?
Yes.
at you make and that you think are reliable enough.
We will contact you before making changes to your code, except for
obviously correct and unquestionable ones.
2006-09-05 Bruno Haible <[EMAIL PROTECTED]>
* MODULES.html.sh (String handling): Add trim.
2006-09-05 Davide Angeloc
Hi Simon,
> The interface sounds good to me, let's see the code. ;)
I'm making some changes to iconvme::iconv_string on the way of the merge.
I've put them on the 'haible-private' branch of lib/iconvme.c. All based
on code in use in GNU gettext for years. What do you think about them?
Acceptable?
Depends-on:
iconv
strdup
c-strcase
configure.ac:
Makefile.am:
lib_SOURCES += striconv.h striconv.c
if GL_COND_LIBTOOL
lib_LDFLAGS += $(LTLIBICONV)
else
lib_LDFLAGS += $(LIBICONV)
endif
Include:
"striconv.h"
License:
LGPL
Maintainer:
Bruno Haible, Simon Josefsson
:
Character set conversion of strings made easy, uses iconv, with out-of-memory
checking.
Files:
lib/xstriconv.h
lib/xstriconv.c
Depends-on:
striconv
xalloc
configure.ac:
Makefile.am:
lib_SOURCES += xstriconv.h xstriconv.c
Include:
"xstriconv.h"
License:
GPL
Maintainer:
Brun
This initializes lib..._LDFLAGS, so that it can be augmented later.
2006-09-05 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_emit_lib_Makefile_am): Initialize also
lib_..._LDFLAGS.
*** gnulib-tool.bak 2006-09-06 01:46:53.0 +0200
--- gnulib-tool 2006
7;s documented in the automake manual.
Objections?
2006-09-05 Bruno Haible <[EMAIL PROTECTED]>
* modules/gc (Makefile.am): Augment lib_LDFLAGS, not lib_LIBADD.
* modules/iconvme (Makefile.am): Likewise. Also handle the case of
not using libtool correctly.
diff -r -
--version
...
Written by Danilo Šegan and Bruno Haible.
$ LC_ALL=C recode-sr-latin --version
...
Written by Danilo Segan and Bruno Haible.
The 'propername' module does exactly this. Plus, for languages that use
a different writing system than the Latin alphabet, it allows a translator
to
Simon Josefsson wrote:
> Please install the patch, if I run into
> any problem later on, I'll report it then.
Done. Let's see how it works out.
Bruno
Eric Blake wrote:
> > $ ptx --version| grep Pinard
> > Écrit par F. Pinard.
>
> This one is a translation bug. coreutils source already has a TRANSLATORS
> note before _("F. Pinard") stating that the translator should use the full
> spelling when ç is available, and since you are showing the
Hello François,
> > Written by Francois Pinard.
> > Written by Franc,ois Pinard.
>
> >Which of the two ASCII transliterations he prefers, François will
> >certainly tell you himself.
>
> Both are good, I would maybe use the second myself.
Thanks. The way to write your name then with the 'prop
Paul Eggert wrote:
> First, the problem occurs not only with proper names, but with any
> text string that is English but not ASCII. English mostly uses plain
> ASCII, but there are exceptions. Many of the exceptions are words
> like naïve that most people will accept in ASCII versions, but some
Jim Meyering wrote:
> I've always taken the stand that
> generated files should be read-only, and this is just another
> reason to follow that policy.
I'm vehemently opposed to such a change. On the contrary, I think the
policy should be that in a distrib tarball, _all_ files and directories
shoul
Jim Meyering wrote:
> I learned long enough ago that
> files like Makefile, Makefile.in, configure, etc. are generated,
> so that their being writable isn't a big deal. But still, for
> novices, ...
Would it help you if we consequently mark every generated file (except
generated doc - info, html,
Bruce Korb wrote:
> Or maybe both of these lines :)
>
>-*- buffer-read-only: t -*- vi: set ro:
>DO NOT EDIT! GENERATED AUTOMATICALLY!
For the user who wants to do small developments, such as tweaks in a
Makefile or config.h, and who happens to use emacs or vi, this is still
a nuisance. (L
Paul Eggert wrote:
> Here's another thought: how about this even-shorter version instead?
>
> alloca.h: alloca_.h
> $(LN_F_S) $(srcdir)/alloca_.h $@
>
> where $(LN_FS) expands to "ln -fs" in the typical case, or to
> "rm -f $@ && cp" on hosts where "ln -fs" doesn't work (e.g., Solaris 9
> a
Sergey Poznyakoff wrote:
> 2006-09-09 Sergey Poznyakoff <[EMAIL PROTECTED]>
>
> * argp-help.c (argp_doc): Split the untranslated doc string on
> '\v', and translate the two parts separately, instead of
> feeding the whole string to gettext. This allows to exclude
>
Sergey Poznyakoff wrote:
> --- error.c 29 Aug 2006 16:58:34 - 1.46
> +++ error.c 9 Sep 2006 05:39:50 -
> @@ -92,9 +92,13 @@ extern void __error_at_line (int status,
> char *strerror_r ();
> # endif
>
> +#ifdef HAVE_PROGRAM_INVOCATION_NAME
> +# define program_name program_invoca
Sergey Poznyakoff wrote:
> If it is called before argp_parse it will
> surely coredump. But then, we cannot guarantee that whoever is using
> this interface will set program_name before calling error(), can we?
We need to document it somewhere, in error.h or argp.h.
Bruno
Sergey Poznyakoff wrote:
> The 'doc' field of argp_option has a different
> semantics, '\v' does not apply to it.
Sure. But N_(...) does apply to it. One might document this, otherwise
the programmer might think that he needs to fill in the translation himself
into the ->doc field at runtime, not
Gary V. Vaughan wrote:
> Untested:
>
> m4_define([gt__NEED_NGETTEXT_FU],
> [shell code to execute after expansion of AM_GNU_GETTEXT,
> whenever AM_GETTEXT_NEED_NGETTEXT is present somewhere])
>
> AC_DEFUN([AM_GNU_GETTEXT],
> [
> ...current contents of AM_GNU_GETTEXT definition...
>
> dnl make
link without libtool.
Nevertheless, packages that build many executables may not want to use
these variables, since they may add too many link dependencies. But for
packages with only one executable these two Makefile variables are perfect.
Bruno
2006-09-09 Bruno Haible <[EMAIL PROTECTED]
Ralf Wildenhues wrote:
> Actually, you should not put `-l*' into LDFLAGS at all,
> those belong into LIBS, *LDADD, or lib*_LIBADD (the latter being useful
> for libtool libraries only).
This is not how automake documents these variables. The doc (node
"Libtool Flags") says that I can augment only
Jim Meyering wrote:
> >> Bruno, would you mind if I changed the uses of "t-$@" to "[EMAIL
> >> PROTECTED]"
> >> in modules/localcharset?
> >
> > Yes. The rule would not work right any more on 8+3 filesystems (DJGPP,
> > possibly also OS/2).
>
> Do you know of actual users who have to _build_ GNU
Jim Meyering wrote:
> > 2) For the user who needs to fix a compilation problem, or do minor
> >developments in a package.
> >
> >In this case I _do_ want to change the Makefile or config.h, to see
> >the results. Because if I change Makefile.am or *.m4, I will have to
> >wait 5 minu
Eric Blake wrote:
> It is not possible to know what macros will be invoked later in the file.
> But with diversions, it is possible for macros invoked later to emit
> shell code that will be invoked earlier, by making sure that
> gt__NEED_NGETTEXT_FU expands to shell code in a lower diversion numb
Sergey Poznyakoff wrote:
> ! inp_text = __strndup (argp->doc, inp_text_len);
> ! }
> ! }
> ! else
> ! inp_text = post ? 0 : argp->doc;
> ! trans_text = dgettext (argp->argp_domain, inp_text);
In either case of the 'if' branch, inp_text can end up being NULL.
B
Hi,
I changed the mkdtemp module so that it uses the complete
replacement.
2006-09-10 Bruno Haible <[EMAIL PROTECTED]>
* mkdtemp.m4 (gl_PREREQ_MKDTEMP): Don't require gl_AC_TYPE_UINTMAX_T.
2006-09-10 Bruno Haible <[EMAIL PROTECTED]>
* mkdtemp.c: Inclu
Ralf Wildenhues wrote:
> > And for executables, an *_LDADD variable exists, but the automake doc says
> > the opposite of what you say:
> >
> >`PROG_LDADD' is inappropriate for passing program-specific linker
> >flags (except for `-l', `-L', `-dlopen' and `-dlpreopen'). So, use the
> >
Ralf Wildenhues wrote:
> Are there usage cases where someone links a program or library with
> libtool, and this uses a libgnu.a rather than a libgnu.la?
Not yet. But why should I introduce an artificial limitation?
Bruno
Simon Josefsson wrote:
> However, it seems arguable correct (right?), so I propose to install
> the patch below in gnulib-tool. Ok?
>
> /Simon
>
> --- gnulib-tool 12 Sep 2006 17:37:41 +0200 1.159
> +++ gnulib-tool 13 Sep 2006 15:50:00 +0200
> @@ -1098,7 +1098,7 @@
>fi
Paul Eggert wrote:
> Since nobody needs
> HAVE_CONFIG_H any more, I installed the following change into gnulib.
I did the same for these files.
2006-09-14 Bruno Haible <[EMAIL PROTECTED]>
* lib/allocsa.c: Include unconditionally.
* lib/asnprintf.c: Likewise.
Ralf Wildenhues wrote:
> CVS Libtool's libltdl allows third-party user code to decide over the
> naming of the config header file it may share with it (and whether to
> use one)
Gettextize doesn't allow this choice, when including intl/ as a subdirectory,
and I'm not aware that anybody complained
Yoann Vandoorselaere wrote:
> The c-ctype, c-strcase, c-strcasestr and c-strstr modules seem only to
> implement their replacement functions using a "c_" prefix.
>
> However, there is no autoconf test implemented by these modules that
> redefine the original function (in case it is missing) to po
Hi,
Jim Meyering wrote:
> +static inline bool
> +has_trailing_slash (char const *file, size_t len)
> +{
> + /* Don't count "/" as having a trailing slash. */
> + if (len <= 1)
> +return false;
> +
> + char last = file[len - 1];
> + return ISSLASH (last);
Since you use ISSLASH, you appare
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
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/javavers
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.
ile as an argument to the autoconf macro (similar to
what we do in gt_JAVAEXEC).
Objections?
2006-09-17 Bruno Haible <[EMAIL PROTECTED]>
* gnulib-tool (func_import, func_create_testdir): Set gl_source_base
at the beginning of the gl_INIT macro.
* m4/getloadavg.m4 (gl_GE
Thanks for the suggestion. I broke the lines now, before the binary
operators (like the GNU standards recommends for C).
Bruno
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
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..
into gnulib on 2006-07-22: Two different
macros, gl_HEADER_INTTYPES_H and gl_AC_HEADER_INTTYPES_H, were using
the same cache variable, with different meanings! Apologies.
I now fixed this by removing one of the two macros.
2006-09-18 Bruno Haible <[EMAIL PROTECTED]>
* m4/inttypes-h
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
401 - 500 of 14814 matches
Mail list logo
