* No declaration for isblank
@ 2007-09-19 21:25 Neil Jerram
2007-09-19 21:31 ` No declaration for cuserid Neil Jerram
2007-09-20 7:34 ` No declaration for isblank Ludovic Courtès
0 siblings, 2 replies; 15+ messages in thread
From: Neil Jerram @ 2007-09-19 21:25 UTC (permalink / raw)
To: Guile Bugs
Compiling current CVS on Debian Etch:
...
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I../lib -I../lib -pthread -g -O2 -Wall -Wmissing-prototypes -Werror -MT libguile_la-srfi-14.lo -MD -MP -MF .deps/libguile_la-srfi-14.Tpo -c srfi-14.c -fPIC -DPIC -o .libs/libguile_la-srfi-14.o
cc1: warnings being treated as errors
srfi-14.c: In function 'scm_srfi_14_compute_char_sets':
srfi-14.c:1532: warning: implicit declaration of function 'isblank'
make[3]: *** [libguile_la-srfi-14.lo] Error 1
make[3]: Leaving directory `/home/neil/Organized/SW/Guile/guile-cvs-head/guile/guile-core/libguile'
...
The patch below cures this, but is it correct?
Regards,
Neil
--- srfi-14.c 29 Jul 2007 14:58:21 -0000 1.6
+++ srfi-14.c 19 Sep 2007 21:25:08 -0000
@@ -17,6 +17,8 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#define _GNU_SOURCE
+
#ifdef HAVE_CONFIG_H
# include <config.h>
#endif
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 15+ messages in thread* No declaration for cuserid
2007-09-19 21:25 No declaration for isblank Neil Jerram
@ 2007-09-19 21:31 ` Neil Jerram
2007-09-20 7:34 ` No declaration for isblank Ludovic Courtès
1 sibling, 0 replies; 15+ messages in thread
From: Neil Jerram @ 2007-09-19 21:31 UTC (permalink / raw)
To: Guile Bugs
Neil Jerram <neil@ossau.uklinux.net> writes:
> Compiling current CVS on Debian Etch:
>
> ...
> gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I../lib -I../lib -pthread -g -O2 -Wall -Wmissing-prototypes -Werror -MT libguile_la-srfi-14.lo -MD -MP -MF .deps/libguile_la-srfi-14.Tpo -c srfi-14.c -fPIC -DPIC -o .libs/libguile_la-srfi-14.o
> cc1: warnings being treated as errors
> srfi-14.c: In function 'scm_srfi_14_compute_char_sets':
> srfi-14.c:1532: warning: implicit declaration of function 'isblank'
And a similar problem for cuserid() in posix.c:
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I.. -I../lib -I../lib -g -O2 -Wall -Wmissing-prototypes -Werror -MT posix.lo -MD -MP -MF .deps/posix.Tpo -c posix.c -fPIC -DPIC -o .libs/posix.o
cc1: warnings being treated as errors
posix.c: In function 'scm_cuserid':
posix.c:1705: warning: implicit declaration of function 'cuserid'
posix.c:1705: warning: assignment makes pointer from integer without a cast
make[3]: *** [posix.lo] Error 1
--- posix.c 11 Sep 2007 00:46:15 -0000 1.167
+++ posix.c 19 Sep 2007 21:30:36 -0000
@@ -15,8 +15,9 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
-
\f
+#define _GNU_SOURCE
+
#if HAVE_CONFIG_H
# include <config.h>
#endif
Regards,
Neil
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: No declaration for isblank
2007-09-19 21:25 No declaration for isblank Neil Jerram
2007-09-19 21:31 ` No declaration for cuserid Neil Jerram
@ 2007-09-20 7:34 ` Ludovic Courtès
2007-10-21 21:13 ` Neil Jerram
1 sibling, 1 reply; 15+ messages in thread
From: Ludovic Courtès @ 2007-09-20 7:34 UTC (permalink / raw)
To: Neil Jerram; +Cc: Guile Bugs
Hi,
Neil Jerram <neil@ossau.uklinux.net> writes:
> The patch below cures this, but is it correct?
No, because M4 macro `gl_EARLY' requires `AC_GNU_SOURCE', which in turn
defines `_GNU_SOURCE' when available.
My `config.h' here contains this:
/* Enable GNU extensions on systems that have them. */
#ifndef _GNU_SOURCE
# define _GNU_SOURCE 1
#endif
If yours doesn't, I suspect you have to run "autoheader && ./configure"
again (or similar).
Let us know if it fixes the problem.
Thanks,
Ludovic.
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: No declaration for isblank
2007-09-20 7:34 ` No declaration for isblank Ludovic Courtès
@ 2007-10-21 21:13 ` Neil Jerram
2007-10-21 21:22 ` Neil Jerram
0 siblings, 1 reply; 15+ messages in thread
From: Neil Jerram @ 2007-10-21 21:13 UTC (permalink / raw)
To: Guile Bugs
ludovic.courtes@laas.fr (Ludovic Courtès) writes:
> Hi,
>
> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> The patch below cures this, but is it correct?
>
> No, because M4 macro `gl_EARLY' requires `AC_GNU_SOURCE', which in turn
> defines `_GNU_SOURCE' when available.
>
> My `config.h' here contains this:
>
> /* Enable GNU extensions on systems that have them. */
> #ifndef _GNU_SOURCE
> # define _GNU_SOURCE 1
> #endif
>
> If yours doesn't, I suspect you have to run "autoheader && ./configure"
> again (or similar).
I tried that, but still have no mention of _GNU_SOURCE in my config.h.
I also did a `find-grep-dired' for gl_EARLY in /usr/share/autoconf and
/usr/share/automake-1.10: no occurrences found at all.
Where is gl_EARLY supposed to be defined? Once I know that, I can
dig deeper about what's not working in my system.
Regards,
Neil
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: No declaration for isblank
2007-10-21 21:13 ` Neil Jerram
@ 2007-10-21 21:22 ` Neil Jerram
2007-10-21 21:51 ` Ludovic Courtès
0 siblings, 1 reply; 15+ messages in thread
From: Neil Jerram @ 2007-10-21 21:22 UTC (permalink / raw)
To: Guile Bugs
Neil Jerram <neil@ossau.uklinux.net> writes:
> ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
>> Hi,
>>
>> Neil Jerram <neil@ossau.uklinux.net> writes:
>>
>>> The patch below cures this, but is it correct?
>>
>> No, because M4 macro `gl_EARLY' requires `AC_GNU_SOURCE', which in turn
>> defines `_GNU_SOURCE' when available.
>>
>> My `config.h' here contains this:
>>
>> /* Enable GNU extensions on systems that have them. */
>> #ifndef _GNU_SOURCE
>> # define _GNU_SOURCE 1
>> #endif
>>
>> If yours doesn't, I suspect you have to run "autoheader && ./configure"
>> again (or similar).
>
> I tried that, but still have no mention of _GNU_SOURCE in my config.h.
>
> I also did a `find-grep-dired' for gl_EARLY in /usr/share/autoconf and
> /usr/share/automake-1.10: no occurrences found at all.
>
> Where is gl_EARLY supposed to be defined? Once I know that, I can
> dig deeper about what's not working in my system.
Inevitably, immediately after sending, I think of something
else... :-)
I've found gl_EARLY now in the Guile source, in m4/gnulib-comp.m4.
But my definition doesn't require AC_GNU_SOURCE:
AC_DEFUN([gl_EARLY],
[
m4_pattern_forbid([^gl_[A-Z]])dnl the gnulib macro namespace
m4_pattern_allow([^gl_ES$])dnl a valid locale name
m4_pattern_allow([^gl_LIBOBJS$])dnl a variable
m4_pattern_allow([^gl_LTLIBOBJS$])dnl a variable
AC_REQUIRE([AC_PROG_RANLIB])
])
gnulib-comp.m4 says it's generated by gnulib-tool, so is the problem
that I don't have a sufficiently up to date version of gnulib-tool?
Mine is:
neil@arudy:~$ gnulib-tool --version
/usr/bin/gnulib-tool (GNU gnulib) 2006-11-29
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Bruno Haible and Simon Josefsson
Regards,
Neil
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: No declaration for isblank
2007-10-21 21:22 ` Neil Jerram
@ 2007-10-21 21:51 ` Ludovic Courtès
2007-10-23 14:06 ` Neil Jerram
0 siblings, 1 reply; 15+ messages in thread
From: Ludovic Courtès @ 2007-10-21 21:51 UTC (permalink / raw)
To: bug-guile
Hi,
Neil Jerram <neil@ossau.uklinux.net> writes:
> I've found gl_EARLY now in the Guile source, in m4/gnulib-comp.m4.
> But my definition doesn't require AC_GNU_SOURCE:
[...]
> neil@arudy:~$ gnulib-tool --version
> /usr/bin/gnulib-tool (GNU gnulib) 2006-11-29
My `gl_EARLY' does require `AC_GNU_SOURCE'. I'm using:
$ gnulib-tool --version
/usr/bin/gnulib-tool (GNU gnulib) 2007-07-01
This is from Debian unstable.
(I couldn't find in Gnulib's Git log whether `AC_GNU_SOURCE' appeared in
between both versions.)
Thanks,
Ludovic.
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: No declaration for isblank
2007-10-21 21:51 ` Ludovic Courtès
@ 2007-10-23 14:06 ` Neil Jerram
2007-10-23 14:27 ` Ludovic Courtès
0 siblings, 1 reply; 15+ messages in thread
From: Neil Jerram @ 2007-10-23 14:06 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: bug-guile
ludo@gnu.org (Ludovic Courtès) writes:
> My `gl_EARLY' does require `AC_GNU_SOURCE'. I'm using:
>
> $ gnulib-tool --version
> /usr/bin/gnulib-tool (GNU gnulib) 2007-07-01
>
> This is from Debian unstable.
>
> (I couldn't find in Gnulib's Git log whether `AC_GNU_SOURCE' appeared in
> between both versions.)
Upgrading gnulib to unstable didn't help.
The problem was lines like the following in /usr/bin/gnulib-tool.
if grep AC_GNU_SOURCE "$destdir"/$m4base/*.m4 >/dev/null 2>/dev/null; then
echo " AC_REQUIRE([AC_GNU_SOURCE])"
So, if you create a file m4/workaround.m4, containing just
"AC_GNU_SOURCE", and then rerun autogen.sh, you get a definition of
gl_EARLY that includes AC_GNU_SOURCE, and the _GNU_SOURCE stuff in
config.h.in.
That seems excessively magic to me, but I suppose we could ensure
correct future behaviour by checking in such a file to CVS. What do
you think?
Regards,
Neil
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: No declaration for isblank
2007-10-23 14:06 ` Neil Jerram
@ 2007-10-23 14:27 ` Ludovic Courtès
2007-10-24 10:30 ` Neil Jerram
0 siblings, 1 reply; 15+ messages in thread
From: Ludovic Courtès @ 2007-10-23 14:27 UTC (permalink / raw)
To: Neil Jerram; +Cc: bug-guile
Hi,
Neil Jerram <neil@ossau.uklinux.net> writes:
> The problem was lines like the following in /usr/bin/gnulib-tool.
>
> if grep AC_GNU_SOURCE "$destdir"/$m4base/*.m4 >/dev/null 2>/dev/null; then
> echo " AC_REQUIRE([AC_GNU_SOURCE])"
>
> So, if you create a file m4/workaround.m4, containing just
> "AC_GNU_SOURCE", and then rerun autogen.sh, you get a definition of
> gl_EARLY that includes AC_GNU_SOURCE, and the _GNU_SOURCE stuff in
> config.h.in.
Hmm, strange. Here I have `extensions.m4' and `gnulib-comp.m4', both of
which require `AC_GNU_SOURCE'. I believe `gnulib-tool --update' is
deterministic when starting with an `m4' directory only containing
`gnulib-cache.m4', so I don't understand how we can get different
results.
Did you try clearing the `m4' dir (expect for `gnulib-cache.m4') and
re-running `gnulib-tool --update'? Assuming we both use the same Gnulib
snapshot, `m4' should contain the same files on both machines. With
Debian's `gnulib-20071001+dfsg-1', I get this:
$ sha1sum m4/*m4
817660373a28ce877ae7efcce4c06ed0bfa93052 m4/alloca.m4
4229cdd16c7512e1c03e1131a3441882bd7ced42 m4/extensions.m4
fa99215ca5959f83eeb093ada23a82622abb194e m4/gnulib-cache.m4
e02774d532c8700d4a722b3f6189d487f0df721e m4/gnulib-common.m4
94693473bd8aa9eddd6e30af2213ebdd5ed31852 m4/gnulib-comp.m4
4d3cae2790230ada32cb11340e797b42bd71e25c m4/gnulib-tool.m4
bf7b7750e03c02566c190514b96a2309daf0c1c1 m4/include_next.m4
f3793585703e62a1c9058f81eb897b08b3342954 m4/onceonly_2_57.m4
14aea4fa9d1cf27c71ac052ed00e4573e437f48f m4/strcase.m4
20a6d0a961ae4f4913ab2162fca088db24bc0b4e m4/string_h.m4
$ grep -n GNU_SOURCE m4/*m4
m4/extensions.m4:45:#ifndef _GNU_SOURCE
m4/extensions.m4:46:# undef _GNU_SOURCE
m4/extensions.m4:72: AC_DEFINE([_GNU_SOURCE])
m4/gnulib-comp.m4:28: AC_REQUIRE([AC_GNU_SOURCE])
(Note that once this is done, you also need to run `autoheader'.)
> That seems excessively magic to me, but I suppose we could ensure
> correct future behaviour by checking in such a file to CVS. What do
> you think?
Normally, only `gnulib-cache.m4' needs to be versioned, since the rest
is installed based on what this file contains [0]. Nevertheless, we
could adjust this if it turns out to be necessary.
Thanks,
Ludovic.
[0] http://www.gnu.org/software/gnulib/manual/html_node/CVS-Issues.html
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: No declaration for isblank
2007-10-23 14:27 ` Ludovic Courtès
@ 2007-10-24 10:30 ` Neil Jerram
2007-10-24 11:19 ` Ludovic Courtès
2007-10-24 11:30 ` No declaration for isblank Neil Jerram
0 siblings, 2 replies; 15+ messages in thread
From: Neil Jerram @ 2007-10-24 10:30 UTC (permalink / raw)
To: bug-guile
ludovic.courtes@laas.fr (Ludovic Courtès) writes:
> Did you try clearing the `m4' dir (expect for `gnulib-cache.m4') and
> re-running `gnulib-tool --update'? Assuming we both use the same Gnulib
> snapshot, `m4' should contain the same files on both machines. With
> Debian's `gnulib-20071001+dfsg-1', I get this:
>
> $ sha1sum m4/*m4
> 817660373a28ce877ae7efcce4c06ed0bfa93052 m4/alloca.m4
> 4229cdd16c7512e1c03e1131a3441882bd7ced42 m4/extensions.m4
> fa99215ca5959f83eeb093ada23a82622abb194e m4/gnulib-cache.m4
> e02774d532c8700d4a722b3f6189d487f0df721e m4/gnulib-common.m4
> 94693473bd8aa9eddd6e30af2213ebdd5ed31852 m4/gnulib-comp.m4
> 4d3cae2790230ada32cb11340e797b42bd71e25c m4/gnulib-tool.m4
> bf7b7750e03c02566c190514b96a2309daf0c1c1 m4/include_next.m4
> f3793585703e62a1c9058f81eb897b08b3342954 m4/onceonly_2_57.m4
> 14aea4fa9d1cf27c71ac052ed00e4573e437f48f m4/strcase.m4
> 20a6d0a961ae4f4913ab2162fca088db24bc0b4e m4/string_h.m4
I had:
2219c92e4e68aa6aa0983cafa8570701e012a315 gnulib-cache.m4
e02774d532c8700d4a722b3f6189d487f0df721e gnulib-common.m4
2152435b51706c5b1ea97cf28b93e45cce895766 gnulib-comp.m4
4d3cae2790230ada32cb11340e797b42bd71e25c gnulib-tool.m4
057209c2c0bb7070fe8d071315fdda16631e19d7 hack.m4
f3793585703e62a1c9058f81eb897b08b3342954 onceonly_2_57.m4
and I've saved these files off in case further analysis of them is
needed.
Then proceeding as you suggested:
==========begin transcript============
neil@arudy:~/Organized/SW/Guile/guile-cvs-head/guile/guile-core$ gnulib-tool --update
Module list with included dependencies:
File list:
lib/dummy.c
m4/gnulib-common.m4
m4/onceonly_2_57.m4
Copying file m4/gnulib-common.m4
Copying file m4/gnulib-tool.m4
Copying file m4/onceonly_2_57.m4
Creating m4/gnulib-comp.m4
Creating ./m4/.cvsignore
Finished.
You may need to add #include directives for the following .h files.
Don't forget to
- add "lib/Makefile" to AC_CONFIG_FILES in ./configure.in,
- mention "lib" in SUBDIRS in Makefile.am,
- mention "-I m4" in ACLOCAL_AMFLAGS in Makefile.am,
- invoke gl_EARLY in ./configure.in, right after AC_PROG_CC,
- invoke gl_INIT in ./configure.in.
neil@arudy:~/Organized/SW/Guile/guile-cvs-head/guile/guile-core$ sha1sum m4/*.m4
2219c92e4e68aa6aa0983cafa8570701e012a315 m4/gnulib-cache.m4
e02774d532c8700d4a722b3f6189d487f0df721e m4/gnulib-common.m4
9da55c6341d6d8838991494074fa0b6a2bbdbb36 m4/gnulib-comp.m4
4d3cae2790230ada32cb11340e797b42bd71e25c m4/gnulib-tool.m4
f3793585703e62a1c9058f81eb897b08b3342954 m4/onceonly_2_57.m4
neil@arudy:~/Organized/SW/Guile/guile-cvs-head/guile/guile-core$ gnulib-tool --version
/usr/bin/gnulib-tool (GNU gnulib) 2007-09-17
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Bruno Haible and Simon Josefsson
==========end transcript============
So I guess the question becomes: why don't alloca.m4 and extensions.m4
appear for me?
Regards,
Neil
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: No declaration for isblank
2007-10-24 10:30 ` Neil Jerram
@ 2007-10-24 11:19 ` Ludovic Courtès
2008-01-30 11:34 ` Ludovic Courtès
2007-10-24 11:30 ` No declaration for isblank Neil Jerram
1 sibling, 1 reply; 15+ messages in thread
From: Ludovic Courtès @ 2007-10-24 11:19 UTC (permalink / raw)
To: Neil Jerram; +Cc: bug-guile
Hi,
Neil Jerram <neil@ossau.uklinux.net> writes:
> ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>> fa99215ca5959f83eeb093ada23a82622abb194e m4/gnulib-cache.m4
> I had:
>
> 2219c92e4e68aa6aa0983cafa8570701e012a315 gnulib-cache.m4
This one differs from mine, which may explain why all the rest differs.
> So I guess the question becomes: why don't alloca.m4 and extensions.m4
> appear for me?
My `gnulib-cache.m4' is the same as the one in CVS HEAD:
http://cvs.savannah.gnu.org/viewvc/guile/guile-core/m4/gnulib-cache.m4?revision=1.1&root=guile&view=markup
It contains the line "gl_MODULES([alloca strcase])" so `gnulib-tool'
must at least pull the `alloca' and `strcase' modules. It should also
pull their dependencies; `strcase' happens to depend on `string', which
in turn depends on `extensions', the module that ensures `_GNU_SOURCE'
is defined when available.
(Actually, we should be importing `extensions' explicitly rather than
rely on this side effect.)
Can you check your `gnulib-cache.m4'?
Thanks,
Ludovic.
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: No declaration for isblank
2007-10-24 11:19 ` Ludovic Courtès
@ 2008-01-30 11:34 ` Ludovic Courtès
2008-01-30 22:19 ` Neil Jerram
0 siblings, 1 reply; 15+ messages in thread
From: Ludovic Courtès @ 2008-01-30 11:34 UTC (permalink / raw)
To: Neil Jerram; +Cc: bug-guile
Hi,
I'm slowly getting back to Guile, and the first thing I came across was
this old Gnulib-related bootstrap issue (HEAD).
ludovic.courtes@laas.fr (Ludovic Courtès) writes:
> My `gnulib-cache.m4' is the same as the one in CVS HEAD:
>
> http://cvs.savannah.gnu.org/viewvc/guile/guile-core/m4/gnulib-cache.m4?revision=1.1&root=guile&view=markup
>
> It contains the line "gl_MODULES([alloca strcase])" so `gnulib-tool'
> must at least pull the `alloca' and `strcase' modules. It should also
> pull their dependencies; `strcase' happens to depend on `string', which
> in turn depends on `extensions', the module that ensures `_GNU_SOURCE'
> is defined when available.
>
> (Actually, we should be importing `extensions' explicitly rather than
> rely on this side effect.)
I followed my own suggestion and added `extensions' to the list of
required modules, since it turns out that it was no longer pulled by the
other modules. Hopefully, that fixes this very problem once for all.
On a related note, when bootstrapping, `autoreconf' complains that we're
using `AM_GNU_GETTEXT' without having `po' in `SUBDIRS'---which is
normal since no string is internationalized. Still, is there something
we could do about it?
Thanks,
Ludovic.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: No declaration for isblank
2008-01-30 11:34 ` Ludovic Courtès
@ 2008-01-30 22:19 ` Neil Jerram
2008-01-31 9:21 ` String translation Ludovic Courtès
0 siblings, 1 reply; 15+ messages in thread
From: Neil Jerram @ 2008-01-30 22:19 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: bug-guile
ludo@gnu.org (Ludovic Courtès) writes:
> Hi,
>
> I'm slowly getting back to Guile, and the first thing I came across was
> this old Gnulib-related bootstrap issue (HEAD).
>
> ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
>> My `gnulib-cache.m4' is the same as the one in CVS HEAD:
>>
>> http://cvs.savannah.gnu.org/viewvc/guile/guile-core/m4/gnulib-cache.m4?revision=1.1&root=guile&view=markup
>>
>> It contains the line "gl_MODULES([alloca strcase])" so `gnulib-tool'
>> must at least pull the `alloca' and `strcase' modules. It should also
>> pull their dependencies; `strcase' happens to depend on `string', which
>> in turn depends on `extensions', the module that ensures `_GNU_SOURCE'
>> is defined when available.
>>
>> (Actually, we should be importing `extensions' explicitly rather than
>> rely on this side effect.)
>
> I followed my own suggestion and added `extensions' to the list of
> required modules, since it turns out that it was no longer pulled by the
> other modules. Hopefully, that fixes this very problem once for all.
Sounds good. I think most of this problem was actually me not
understanding how gnulib works, but I agree that it makes sense to
import extensions explicitly.
> On a related note, when bootstrapping, `autoreconf' complains that we're
> using `AM_GNU_GETTEXT' without having `po' in `SUBDIRS'---which is
> normal since no string is internationalized. Still, is there something
> we could do about it?
I guess we could start some token internationalization... Perhaps we
could start with the "ERROR" in display_header(), and who knows where
that might lead? Translation of Guile's messages can only be a good
thing, n'est-ce pas?
(On the other hand, I haven't noticed anyone clamouring for this.)
> Thanks,
> Ludovic.
Regards,
Neil
^ permalink raw reply [flat|nested] 15+ messages in thread* String translation
2008-01-30 22:19 ` Neil Jerram
@ 2008-01-31 9:21 ` Ludovic Courtès
2008-02-01 20:46 ` Neil Jerram
0 siblings, 1 reply; 15+ messages in thread
From: Ludovic Courtès @ 2008-01-31 9:21 UTC (permalink / raw)
To: Neil Jerram; +Cc: bug-guile
Hi,
Neil Jerram <neil@ossau.uklinux.net> writes:
> ludo@gnu.org (Ludovic Courtès) writes:
>> On a related note, when bootstrapping, `autoreconf' complains that we're
>> using `AM_GNU_GETTEXT' without having `po' in `SUBDIRS'---which is
>> normal since no string is internationalized. Still, is there something
>> we could do about it?
Note that I was initially looking for a quick solution to make
`autoreconf' happier. Having an empty `po' directory is one solution
(admittedly an ugly one).
> I guess we could start some token internationalization... Perhaps we
> could start with the "ERROR" in display_header(), and who knows where
> that might lead? Translation of Guile's messages can only be a good
> thing, n'est-ce pas?
He he. ;-)
Actually, I'm wondering whether it would be a good idea since some
messages have been used in programs as error condition descriptions,
most notably in the test suite, because they provide more information
that just the `throw' key. Thus, translating error messages may have
undesirable side effects.
OTOH, we could try too look at these exceptions whose messages are used
in programs and try to rework them so that programs don't have to rely
on messages to understand what's going on. That could only be done in
HEAD, though, and we could hardly avoid the introduction of
incompatibilities, I think.
Thanks,
Ludovic.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: String translation
2008-01-31 9:21 ` String translation Ludovic Courtès
@ 2008-02-01 20:46 ` Neil Jerram
0 siblings, 0 replies; 15+ messages in thread
From: Neil Jerram @ 2008-02-01 20:46 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: bug-guile
ludovic.courtes@inria.fr (Ludovic Courtès) writes:
> Actually, I'm wondering whether it would be a good idea since some
> messages have been used in programs as error condition descriptions,
> most notably in the test suite, because they provide more information
> that just the `throw' key. Thus, translating error messages may have
> undesirable side effects.
>
> OTOH, we could try too look at these exceptions whose messages are used
> in programs and try to rework them so that programs don't have to rely
> on messages to understand what's going on. That could only be done in
> HEAD, though, and we could hardly avoid the introduction of
> incompatibilities, I think.
Agreed (with all points). In principle, I think that it would be nice
to start translating Guile, and that we should fix exception
information so that programs don't have to rely on particular English
text.
Personally, though, I already have enough stuff going on at the
moment, so I don't plan to investigate this any further myself for
now.
Regards,
Neil
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: No declaration for isblank
2007-10-24 10:30 ` Neil Jerram
2007-10-24 11:19 ` Ludovic Courtès
@ 2007-10-24 11:30 ` Neil Jerram
1 sibling, 0 replies; 15+ messages in thread
From: Neil Jerram @ 2007-10-24 11:30 UTC (permalink / raw)
To: bug-guile
Neil Jerram <neil@ossau.uklinux.net> writes:
> So I guess the question becomes: why don't alloca.m4 and extensions.m4
> appear for me?
OK, problem solved now, and was all my fault. Since switching to a
different machine, I've been running cvs update without the -d option
(because I forgot to copy over my .cvsrc), so I hadn't picked up the
CVS version of m4/gnulib-cache.m4.
Sorry for the hassle!
Neil
_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2008-02-01 20:46 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-19 21:25 No declaration for isblank Neil Jerram
2007-09-19 21:31 ` No declaration for cuserid Neil Jerram
2007-09-20 7:34 ` No declaration for isblank Ludovic Courtès
2007-10-21 21:13 ` Neil Jerram
2007-10-21 21:22 ` Neil Jerram
2007-10-21 21:51 ` Ludovic Courtès
2007-10-23 14:06 ` Neil Jerram
2007-10-23 14:27 ` Ludovic Courtès
2007-10-24 10:30 ` Neil Jerram
2007-10-24 11:19 ` Ludovic Courtès
2008-01-30 11:34 ` Ludovic Courtès
2008-01-30 22:19 ` Neil Jerram
2008-01-31 9:21 ` String translation Ludovic Courtès
2008-02-01 20:46 ` Neil Jerram
2007-10-24 11:30 ` No declaration for isblank Neil Jerram
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).