Re: build problems

[Ken Raeburn]

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" > "address@hidden"
+         "$(snarf_doc).scm" > "address@hidden"
        mv "address@hidden" "$@"
 
 CLEANFILES += $(snarf_doc).texi

Okay to check these in?

Ken