[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: build problems
From: |
Ken Raeburn |
Subject: |
Re: build problems |
Date: |
Thu, 4 Mar 2010 10:19:34 -0500 |
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