The variable name is $makefile_name, the command-line option is
--makefile-name
--
Chuck
2006-11-02 Charles Wilson <...>
* gnulib-tool: fix typo
Index: gnulib-tool
===
RCS file: /sources/gnulib/gnulib/gnulib-tool,v
retr
I'd like to propose the following module for inclusion in gnulib. It is
currently in use by libiconv and gettext under an LGPL license. The
code originally derives from the GNU C library, but has been separately
maintained in the gettext package by Bruno Haible since at least
gettext-0.12 (Ma
[EMAIL PROTECTED] (Karl Berry) writes:
> How do people maintain the list of Gnulib source files for POTFILES.in?
I do it by hand, but have toyed with having the bootstrap script do
it. It already maintains .cvsignore and .gitignore files.
Great. But I wonder if there is one malfunction still in the script.
What if the escape character isn't preceeded by a whitespace? Or am I
wrong? Consider
"\
"
" \
"
This will result in "" and ". But maybe this doesn't matter?
Hi!
2006/11/1, Eric Blake <[EMAIL PROTECTED]>:
Which shell are you using? Bash 3.2.0 had a bug in parsing # inside ``;
it was fixed in bash 3.2.1.
I don't know. :-) Most likely version 2.05b.0(1). Its for sure smaller
than 3.1.0(1). %-)
The reson for this dizzyness is because I have bashdb t
(Back on this week-old message, sorry.)
If the "GNU coding standards" guidelines suggest not to include "why"
a change was made in a ChangeLog entry, then it should be corrected.
What they suggest is to include the reason for a change as a comment in
the code. From
http://www.gnu.org/pre
How do people maintain the list of Gnulib source files for POTFILES.in?
Other than simply tracking the ever-changing list of sources, is there
any built-in support of some kind?
I can imagine writing a script that greps the gnulib dir or whatever,
but maybe it's already been worked out?
Thanks,
k
Bruno Haible <[EMAIL PROTECTED]> writes:
> clean-temp.c:277: xmalloc (new_allocated * sizeof (struct tempdir *
> volatile));
> fatal-signal.c:210: xmalloc (new_actions_allocated * sizeof
> (actions_entry_t));
> fstrcmp.c:623: buffer = (int *) xmalloc (bufmax * (2 * sizeof (int
Eric Blake wrote:
> Another candidate for fixing:
>
> g++ -I. -g -O2 -MT strcasecmp.o -MD -MP -MF .deps/strcasecmp.Tpo -c -o
> strcasecmp.o strcasecmp.c
> In file included from mbchar.h:149,
> from mbuiter.h:101,
> from strcasecmp.c:29:
> /usr/include/string
Eric Blake wrote:
> I'm trying that idea (using CC=g++ on Linux) on M4 before releasing m4 1.4.8.
>
> Is it worth fixing the vasnprintf module?
>
> g++ -I. -g -O2 -MT printf-parse.o -MD -MP -MF .deps/printf-parse.Tpo -c
> -o
> printf-parse.o printf-parse.c
> printf-parse.c: In function
Eric Blake byu.net> writes:
> > Yes. Currently I see no point in making all the replacement modules compile
> > in C++ mode. Only those used in a build on a Linux system are needed,
> > because the purpose of type checking can be achieved on Linux.
>
> I'm trying that idea (using CC=g++ on Linux
Bruno Haible clisp.org> writes:
>
> Jim Meyering wrote:
> > but since it's just one
>
> Yes. Currently I see no point in making all the replacement modules compile
> in C++ mode. Only those used in a build on a Linux system are needed,
> because the purpose of type checking can be achieved on L
Eric Blake byu.net> writes:
>
> On Linux, a c++ compile failed to pick up that the system mkstemp was
adequate,
> due to misuse of a keyword. I'm checking this in.
And this followup to mkstemp-safer.
2006-11-01 Eric Blake <[EMAIL PROTECTED]>
* lib/mkstemp-safer.c (mkstemp_safer):
On Linux, a c++ compile failed to pick up that the system mkstemp was adequate,
due to misuse of a keyword. I'm checking this in.
2006-11-01 Eric Blake <[EMAIL PROTECTED]>
* m4/mkstemp.m4 (gl_FUNC_MKSTEMP): Allow C++ configuration.
Index: m4/mkstemp.m4
===
Paul Eggert wrote:
> I installed this patch instead.
Thanks.
> I prefer to put it into a C++ ghetto area of the code.
I was hesitating about this too.
What I realize now is that we are using xmalloc() too often, and xnmalloc()
not often enough. xnmalloc() is designed to be safe against integer
Jim Meyering wrote:
> but since it's just one
Yes. Currently I see no point in making all the replacement modules compile
in C++ mode. Only those used in a build on a Linux system are needed,
because the purpose of type checking can be achieved on Linux.
> and I see no way around it, ok.
OK, ap
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 10/31/2006 11:03 PM:
>> 2006-10-31 Eric Blake <[EMAIL PROTECTED]>
>>
>> * lib/getopt_.h: Fix comments.
>
> Thanks, please install.
Done.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PRO
Roger Persson wrote:
> I get a strange sed warning/error of "unterminated substitute pattern"
> while using gnulib-tool. I'm building bison and the bootstrapping
> process uses gnulib-tool. ...
>
> I tracked down the failure to a regular expression in
> "func_get_automake_snippet" in gnulib-tool:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Perrog on 10/31/2006 1:36 PM:
> Hi!
>
> I get a strange sed warning/error of "unterminated substitute pattern"
> while using gnulib-tool. I'm building bison and the bootstrapping
> process uses gnulib-tool. I manage to build bison complet
Bruno Haible <[EMAIL PROTECTED]> wrote:
> This is one of 2 more changes needed for C++ compilation of GNU gettext
> without errors.
>
> Is this acceptable?
This is borderline.
Obviously, in general, we should try to avoid casts,
but since it's just one, and I see no way around it, ok.
> 2006-10-2
20 matches
Mail list logo
