| 1 |
I have raised the topic of sbcl bootstrapping some months ago on this |
| 2 |
list: |
| 3 |
https://archives.gentoo.org/gentoo-lisp/message/c6c615f31f29027e0f7d0f98199c65dc |
| 4 |
|
| 5 |
That time, I only considered bootstrapping because it felt closer to |
| 6 |
Gentoo way. Now I'm going into this again for rather more pragmatic |
| 7 |
reasons. |
| 8 |
|
| 9 |
I recently tried a uClibc hardened profile. It worked better than I |
| 10 |
expected but there were some issues, and one of them was emerging |
| 11 |
sbcl. The shipped binary wouldn't run so normal build failed. Thus, I |
| 12 |
believe a bootstrap support is necessary after all. |
| 13 |
|
| 14 |
I'd like to discuss my approach to introducing bootstrap feature to the |
| 15 |
ebuild. It had been tested: I emerged sbcl built with clisp. The overall |
| 16 |
changes ended up being sort of involved, which is why I'd like to |
| 17 |
discuss here first, before attempting a PR or creating a Bugzilla |
| 18 |
entry. I don't have much experience with ebuilds, and I prefer things |
| 19 |
customizable, so my proposal might be too much. |
| 20 |
|
| 21 |
I added the following USE flags: - a `bootstrap' flag which triggers the |
| 22 |
feature - seven flags to specify seven possible compilers, all mutually |
| 23 |
exclusive according to REQUIRED-USE - a `bootstrap-self' flag which |
| 24 |
tells the newly built sbcl to recompile itself prior to install |
| 25 |
|
| 26 |
In addition, a compiler does not have to be specified on a USE flag |
| 27 |
level, namely: when no compiler is explicitly set, the compiler is |
| 28 |
assumed to be `lisp', which means “default lisp,” and a symlink |
| 29 |
`/usr/bin/lisp' is to be governed by |
| 30 |
`app-eselect/eselect-lisp'. sbcl-binary is not fetched when bootstrap is |
| 31 |
set. |
| 32 |
|
| 33 |
Regarding the linked previous discussion of sbcl bootstrapping here, I |
| 34 |
believe the issues mentioned there could be mitigated by adding ewarns |
| 35 |
along the lines of "You've set the bootstrap flag. Don't send bug |
| 36 |
reports!" but this might not be enough if sbcl built this way is then |
| 37 |
used to compile other ones. "Don't send us bugreports EVER until you |
| 38 |
-bootstrap and it succeeds" could then do the trick, I guess. "NO BUG |
| 39 |
REPORTS PLEASE" could be added to the flag description as well. |
| 40 |
|
| 41 |
Now, to the more problematic stuff. |
| 42 |
|
| 43 |
One particular decision that one might find questionable, was providing |
| 44 |
USE flags for all lisps, even though it's not clear if sbcl can be |
| 45 |
bootstrapped with them at all. While in some cases it might make sense |
| 46 |
to remove USE flag until better times, I believe having them all present |
| 47 |
is reasonable, as sbcl is expected to be bootstrappable by any ANSI |
| 48 |
compliant Lisp. Which is why I believe it makes sense to mask these USE |
| 49 |
flags on a profile level if necessary, and only if persistent problems |
| 50 |
with the corresponding lisp are encountered, or if it's not ANSI |
| 51 |
compliant (at least in some practically feasible sense). Furthermore, |
| 52 |
their presence makes a tester's life a little easier, even if just a |
| 53 |
little, and for some testers, it could be more than that, who knows. |
| 54 |
|
| 55 |
Another questionable thing is `app-eselect/eselect-lisp', more so since |
| 56 |
it doesn't exist yet. I believe it does have its uses outside of this |
| 57 |
particular issue---e.g., it would allow for shipping a simple default |
| 58 |
working config for SLIME when SLIME is installed from Portage. Clearly, |
| 59 |
packages for other applications written in Common Lisp could employ |
| 60 |
this. |
| 61 |
|
| 62 |
It might be necessary to replace `eselect-lisp' with |
| 63 |
`eselect-commonlisp', ditto `/usr/bin/lisp'. I hope it doesn't have to |
| 64 |
be like this. |
| 65 |
|
| 66 |
What do you think? |
Archives