Andy Wingo <wi...@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
