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

Reply via email to