Re: [PATCH] Fix hanging of popen.test

[Neil Jerram <neil@ossau.uklinux.net>]

Andy Wingo <wingo@pobox.com> writes:

> This has been an on-and-off issue:
> 02fcbf78b27788c03563e5c3d297a4cd469ce562, and
> 04af4c4c5221c082905d52eb5ad3829ed681d097.

Right.  The commit (4f99a499197b592a9a3060de2205531852f4f94) that
Patrick McCarty identified (with git bisect) is another very similar
case.

Even if we fix this particular one, it seems likely that similar cases
will keep arising, so a more general fix would be better.

The general problem is that any #:use-module or (@ ...) that indirectly
pulls in srfi-1, in any code that is run as part of Guile startup, will
cause the build to fail when doing the snarf-check-and-output-texi,
because libguile-srfi-srfi-13-14-v-4 hasn't been built at that point.

But if the developer concerned happens to have a compatible
libguile-srfi-srfi-13-14-v-4 and libguile installed in /usr/lib or
/usr/local/lib, the build may pick those up and so mask the problem.

Is there a reason why we don't just move all the SRFI C code into the
core libguile?  I think that would be a general fix.

Alternatively we could try making snarf-check-and-output-texi happen
later in the build.  But I had a quick go at that and found it tricky,
because of the dependency on all the .doc files, and those being listed
and generated by libguile/Makefile.am; if we moved the
snarf-check-and-output-texi step to, say, doc/Makefile.am, we'd lose
that dependency.

> I don't really get it. I thought this was fixed. There have been a
> couple threads about this, even, if you search the archives in recent
> months.

I've checked the one starting at
http://lists.gnu.org/archive/html/guile-devel/2010-06/msg00029.html.
But I think it just covers one particular case, that you fixed.

Regards,
      Neil