[gentoo-lisp] SBCL bootstrapping support (again)

[Akater <nuclearspace@gmail.com>]

I have raised the topic of sbcl bootstrapping some months ago on this
list:
https://archives.gentoo.org/gentoo-lisp/message/c6c615f31f29027e0f7d0f98199c65dc

That time, I only considered bootstrapping because it felt closer to
Gentoo way. Now I'm going into this again for rather more pragmatic
reasons.

I recently tried a uClibc hardened profile. It worked better than I
expected but there were some issues, and one of them was emerging
sbcl. The shipped binary wouldn't run so normal build failed. Thus, I
believe a bootstrap support is necessary after all.

I'd like to discuss my approach to introducing bootstrap feature to the
ebuild. It had been tested: I emerged sbcl built with clisp. The overall
changes ended up being sort of involved, which is why I'd like to
discuss here first, before attempting a PR or creating a Bugzilla
entry. I don't have much experience with ebuilds, and I prefer things
customizable, so my proposal might be too much.

I added the following USE flags: - a `bootstrap' flag which triggers the
feature - seven flags to specify seven possible compilers, all mutually
exclusive according to REQUIRED-USE - a `bootstrap-self' flag which
tells the newly built sbcl to recompile itself prior to install

In addition, a compiler does not have to be specified on a USE flag
level, namely: when no compiler is explicitly set, the compiler is
assumed to be `lisp', which means “default lisp,” and a symlink
`/usr/bin/lisp' is to be governed by
`app-eselect/eselect-lisp'. sbcl-binary is not fetched when bootstrap is
set.

Regarding the linked previous discussion of sbcl bootstrapping here, I
believe the issues mentioned there could be mitigated by adding ewarns
along the lines of "You've set the bootstrap flag. Don't send bug
reports!" but this might not be enough if sbcl built this way is then
used to compile other ones. "Don't send us bugreports EVER until you
-bootstrap and it succeeds" could then do the trick, I guess. "NO BUG
REPORTS PLEASE" could be added to the flag description as well.

Now, to the more problematic stuff.

One particular decision that one might find questionable, was providing
USE flags for all lisps, even though it's not clear if sbcl can be
bootstrapped with them at all. While in some cases it might make sense
to remove USE flag until better times, I believe having them all present
is reasonable, as sbcl is expected to be bootstrappable by any ANSI
compliant Lisp. Which is why I believe it makes sense to mask these USE
flags on a profile level if necessary, and only if persistent problems
with the corresponding lisp are encountered, or if it's not ANSI
compliant (at least in some practically feasible sense). Furthermore,
their presence makes a tester's life a little easier, even if just a
little, and for some testers, it could be more than that, who knows.

Another questionable thing is `app-eselect/eselect-lisp', more so since
it doesn't exist yet. I believe it does have its uses outside of this
particular issue---e.g., it would allow for shipping a simple default
working config for SLIME when SLIME is installed from Portage. Clearly,
packages for other applications written in Common Lisp could employ
this.

It might be necessary to replace `eselect-lisp' with
`eselect-commonlisp', ditto `/usr/bin/lisp'. I hope it doesn't have to
be like this.

What do you think?