I was doing some bisecting. I started at v2.0.0, did a full clean and
build then went to df1297956211b7353155c9b54d7e9c22d05ce493 and built
without a "clean". However I got an error:
GUILEC web/request.go
;;; note: source file /home/wingo/src/guile/module/web/uri.scm
;;; newer than compiled /home/wingo/src/guile/module/web/uri.go
[...]
986: 1 [declare-uri-header! "Content-Location"]
In module/ice-9/boot-9.scm:
119: 0 [#<procedure f79050 at module/ice-9/boot-9.scm:110:6 (thrown-k .
args)> unbound-variable ...]
module/ice-9/boot-9.scm:118:20: In procedure #<procedure f79050 at
module/ice-9/boot-9.scm:110:6 (thrown-k . args)>:
module/ice-9/boot-9.scm:118:20: In procedure module-lookup: Unbound
variable: %uri?-procedure
This indicates that (web request) uses (web http) which calls uri? on
something. (web http) is up-to-date, and so the .go file is used. When
the .go was compiled, `uri?' expanded to reference `%uri?-procedure',
but 531c9f1dc51c4801c4d031ee80a31f15285a6b85 changed the names of the
private procedures to have a space instead of a dash, so the new uri.scm
is incompatible with the old web/http.go.
Note that this situation would be even worse if we generated a unique
name for the uri? procedure when uri.scm was compiled, as has been
discussed in http://thread.gmane.org/gmane.lisp.guile.devel/11722.
What should we do here? Here are a few options:
1) Require people to recompile all the time. Sucks.
2) Implement some sort of proper dependency management. Tricky,
because installing a new version of package A could force a
recompile of all dependent packages; tough to get right on a
package-management level.
3) Declare that private names referenced by macro expansions are
actually API that should not break.
Regards,
Andy
--
http://wingolog.org/
