Re: build problems

[Ludovic Courtès]

Hi,

Ken Raeburn <address@hidden> writes:

> On Mar 2, 2010, at 05:23, Ludovic Courtès wrote:
>>>> 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
>> 
>> Keep in mind that ‘c-tokenize.c’ is part of the distribution, so we
>> shouldn’t worry much about what Flex implementations do, as long as the
>> file we ship compiles fine.
>
> True for most people (if they don't do things that cause timestamps to 
> randomly get updated, like using a version control system or copy program 
> that doesn't preserve timestamps), though that just pushes the compatibility 
> issue over to whatever lex/flex version the person building the distribution 
> has....  But, as long as they try it out before putting it up for download, 
> we should catch any problems fairly easily.

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)

$ grep yyget_leng libguile/c-tokenize.lex
int yyget_leng (void);
--8<---------------cut here---------------end--------------->8---

>>> -         "$(srcdir)/$(snarf_doc).scm" > "address@hidden"
>>> +         "$(snarf_doc).scm" > "address@hidden"
>> 
>> This one seems wrong to me since $(snarf_doc).scm is in $(srcdir), not
>> $(builddir).
>
> 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.

On Unix passing absolute paths sort-of works around the problem because
they provide enough naming context, provided the caller and callee see
the same file system hierarchy and have the same permissions.

Now, another interesting (but orthogonal) issue is what to do with
‘load’ when it’s passed *literal* relative paths, as in ‘(load
"../foo.scm")’.  It’s an open issue:
http://lists.gnu.org/archive/html/bug-guile/2009-11/msg00001.html .

>> Can you confirm and commit?
>
> Sure -- done, and done.

Thanks!

Ludo’.