On Tue, 1 Dec 2020, Ryan Schmidt wrote:
On Dec 1, 2020, at 00:07, Ken Cunningham wrote:
another reasonably simple option would be to have a manual step, and
copy what happens with apple-gcc42 +bootstrap.
We make up a non-TLS variant of libcxx, call it libcxx +bootstrap, and
default to installing that if there is nothing in
/usr/lib/libc++.dylib.
Then the port notes (like apple-gcc42) would tell people what to do:
require the installation of clang-5.0, then run:
sudo port install libcxx -bootstrap
and that gets the binary installed.
From then on, people would just have to
sudo port install libcxx
and they would get the TLS version.
apple-gcc42's +bootstrap variant is not suitable for the buildbot either
because of that manual step. The solution would be to change it to a
apple-gcc42-bootstrap subport that installs its files somewhere else,
and apple-gcc-42 (non-bootstrap) knows how to use those files to build
itself.
I've wondered about that variant vs. subport issue myself. I don't think
there's a need for "somewhere else" as long as it uses a different name.
MacPorts compilers already use nonstandard names, so that would just
require using a different nonstandard name.
In fact, I think it would make sense for bootstrap compilers to be
full-fledged compilers in the sense of having "MacPorts compiler names",
with the only abnormality being that they shouldn't be considered to be
compiler candidates by default. They're probably also not reasonable
choices for gcc_select or clang_select.
Fred Wright