
The half strap: self-hosting and Guile - epsylon
https://wingolog.org/archives/2016/01/11/the-half-strap-self-hosting-and-guile
======
davexunit
I've built the new Guile from source a handful of times now. It's definitely a
slow process, but I'm very grateful that Guile doesn't require an older
version of itself in order to build like a lot of other self-hosted languages.
Self-hosting is good, but it's imperative that users can bootstrap on their
own so that they don't have to place trust in a pre-built binary of the
compiler in order to build the compiler. For example, Go has a self-hosted
compiler now, but you don't need to trust a pre-built Go compiler binary to
build Go, because you can bootstrap it using gccgo.

~~~
mintplant
It's good that it doesn't require it, but it sounds like it would be nicer if
the Guile build system offered the option of using a trusted build of the
compiler to compile itself, if you have one lying around.

~~~
davexunit
It does. You can set the GUILE_FOR_BUILD environment variable.

------
outworlder
I like Chicken Scheme's take on this. Since Chicken's compiler always
generates C code, which is then compiled by GCC (or Clang), one just releases
both the source and the compiled scheme files(which are C sources).

Then, it's just "make" as usual.

I've even used this strategy to run a scheme program on iOS, trivially. You
just have to ask it to stop at the C code generation and not invoke the C
compiler. You then insert both chicken's C code and your program's in the
xcode project, and call libchicken's initialization code from Objective-C. And
then compile the whole blob with clang.

EDIT: :%s/compiled C/compiled scheme/g

~~~
davexunit
>like Chicken Scheme's take on this. Since Chicken's compiler always generates
C code, which is then compiled by GCC (or Clang), one just releases both the
source and the compiled C files.

Shipping a pre-built binary is what Guile purposely doesn't do to avoid the
trust issue. Chicken's technique doesn't cut it.

~~~
outworlder
Sorry, my bad. I said "compiled C files" when I meant said "compiled scheme
files", which are C sources, not binaries.

~~~
davexunit
They are binaries, effectively. They are not source code, just like minified
JavaScript code is not source code. Thanks for pointing this out to me. I work
on a package manager with a Chicken package where this sort of thing is
unacceptable, so I've filed a bug.

Does anyone who works on Chicken know how bootstrap it?

~~~
outworlder
You may want to ask on the chicken-users list (chicken-users@nongnu.org,
subscribe at [https://lists.nongnu.org/mailman/listinfo/chicken-
users](https://lists.nongnu.org/mailman/listinfo/chicken-users)). The current
list of maintainers is at ([http://wiki.call-
cc.org/maintainers](http://wiki.call-cc.org/maintainers)), you could also
contact them directly. Or on free node's #chicken

Now, the C source is not included in the repository itself, so if you are
(somehow) building from that(for instance, you already have a working
chicken), you are ok. They are only included in the "release tarballs".

How does your package manager get around bootstrapping compilers, in general?
Guile's approach requires maintaining a one-shot interpreter/compiler in C,
that's only ever used once. I don't think all projects do that.

