Re: build problems

[Ken Raeburn]

On Mar 4, 2010, at 05:52, Ludovic Courtès wrote:
> I have this:
> 
> --8<---------------cut here---------------start------------->8---
> $ grep yyget_leng libguile/c-tokenize.c
> int yyget_leng (void);
> int yyget_leng (void );
> int yyget_leng  (void)

Iiiiinteresting... looks like Apple's not using the 2.5.35 code as released.
Though, in the flex CVS repository, this code has been changed to use 
yy_size_t, so it would probably become a problem with the next release anyways.

>> Yes, though changing load-module to interpret paths relative to the
>> working directory rather than the currently loading module looks wrong
>> too.
> 
> Think about it:
> 
>  $ cd src/guile
> 
>  $ make -C module module/ice-9/q.go
>  make: Entering directory `/home/ludo/src/guile/module'
>  make: *** No rule to make target `module/ice-9/q.go'.  Stop.
>  make: Leaving directory `/home/ludo/src/guile/module'
> 
>  $ make -C module ice-9/q.go
>  make: Entering directory `/home/ludo/src/guile/module'
>  make: `ice-9/q.go' is up to date.
>  make: Leaving directory `/home/ludo/src/guile/module'
> 
>  $ ls ice-9/q.scm
>  ls: cannot access ice-9/q.scm: No such file or directory
> 
>  $ ls module/ice-9/q.scm
>  module/ice-9/q.scm
> 
> Here it’s really an instance of the same problem: the naming context is
> lacking from the relative path.  The only sane way to fix this kind of
> issue is by passing a file descriptor instead of a path, where the file
> descriptor is obtained by resolving a path (relative or absolute) on the
> caller’s side.

I think being explicit about how a relative path is interpreted is often 
adequate, if occasionally messy.  Here, it's relative to the '-C' directory, 
which in turn is relative to the current directory.  You don't usually solve 
this by using "make -C module /path/to/my/guile/tree/module/ice-9/q.go", even 
if you ignore the need to match target strings for getting dependencies from 
the makefile (since targets "/path/to/foo.go" and "foo.go" aren't treated as 
the same).  But, I'm familiar with "make -C", and the behavior to expect from 
"make-texinfo.scm" isn't immediately obvious to me. :-)

The "ln" program highlights the issue too, if you look at "ln" vs "ln -s" for 
creating links that aren't in the directory where ln is being run.  For "ln" 
the name is interpreted relative to the current directory, and absolute names 
work just as well; for "ln -s" the string isn't interpreted by ln but will 
later be interpreted by the file system, relative to its place in the file 
system, and absolute paths may not work if you need the directory tree to be 
relocatable.  Which reminds me...

Hard-coding uses of $(abs_srcdir) nails down a build tree to a specific 
location in the file system.  If I do something like "mv Desktop/guile 
devel/guile", then, without this change to use $(abs_srcdir), the directory 
references in debug info in any previously compiled objects might be wrong if 
the compiler converts them to absolute paths, but otherwise everything would be 
okay except for one use of $(abs_top_srcdir) in examples/Makefile, which 
usually I'm ignoring anyways :-); now, even "make clean" isn't enough, I'll 
need to re-run config.status (or configure) to make doc/ref/Makefile work again 
if I ever need to rebuild standard-library.texi.  This could be occasionally 
annoying.

Ken