On Feb 15, 2010, at 08:41, Ken Raeburn wrote:
> #1: c-tokenize.lex declares yyget_leng() as returning int, but the flex
> template defines it as returning yy_size_t (which is size_t, a.k.a. unsigned
> long), so c-tokenize.c doesn't compile. Changing the declaration in
> c-tokenize.lex to return size_t works for me, but the file hasn't been
> changed in some time, so if "int" was working for other platforms, changing
> it could be a problem.
>
> We don't actually reference yyget_leng elsewhere explicitly; can we just get
> rid of the declaration?
This patch has been working fine for me on my Mac; we may be able to delete
more of the declarations, depending what other lex implementations do, but I
haven't explored that yet and the others aren't causing problems. (And my
Debian box hasn't yet got all the various libraries Guile now depends on, so I
still haven't tested that configuration, but flex has the same version number
as on my Mac.)
Don't declare yyget_leng.
diff --git a/libguile/c-tokenize.lex b/libguile/c-tokenize.lex
index 938a5d2..f801526 100644
--- a/libguile/c-tokenize.lex
+++ b/libguile/c-tokenize.lex
@@ -29,7 +29,6 @@ int yylex(void);
int yyget_lineno (void);
FILE *yyget_in (void);
FILE *yyget_out (void);
-int yyget_leng (void);
char *yyget_text (void);
void yyset_lineno (int line_number);
void yyset_in (FILE * in_str);
> #2: I build outside the source tree, with "../relative/path/to/configure
> --prefix=whatever ...", and make-texinfo.scm was failing for me. After some
> time chasing things down with the debugger (thanks Andy for reminding me to
> recompile to get debug info) and the moral equivalent of debugging printfs, I
> found that load-module in boot-9.scm tries to interpret a relative path as
> relative to the filename for the current-load-port, if there is one. Since
> the currently loading file was "../../../doc/ref/make-texinfo.scm" and the
> supplied filename (given on the command line) was
> "../../../doc/ref/standard-library.scm", load-module jammed the two prefixes
> together and came up with a pathname pointing off to nowhere.
>
> Changing Makefile.am to remove the "$(srcdir)" prefix works around this,
> though I can't help but think there may be other potential cases where a
> relative path *not* coded directly in the loading module itself may be
> intended to be relative to the current directory and not the loading module's
> directory.
Assuming the current 'load-module' behavior is correct -- or not so obviously
incorrect that we're going to change it right now -- this patch takes care of
this build problem for me.
Path for snarf_doc input is treated relative to make-texinfo.scm file.
diff --git a/doc/ref/Makefile.am b/doc/ref/Makefile.am
index a587343..1da5cde 100644
--- a/doc/ref/Makefile.am
+++ b/doc/ref/Makefile.am
@@ -150,7 +150,7 @@ include standard-library.am
$(snarf_doc).texi: $(standard_library_scm_files)
GUILE_AUTO_COMPILE=0 \
"$(preinstguile)" "$(srcdir)/make-texinfo.scm" \
- "$(srcdir)/$(snarf_doc).scm" > "$...@.tmp"
+ "$(snarf_doc).scm" > "$...@.tmp"
mv "$...@.tmp" "$@"
CLEANFILES += $(snarf_doc).texi
Okay to check these in?
Ken
