Building Clang 8/9 in El Capitan

[Ryan Schmidt]

On Feb 13, 2021, at 03:03, Ken Cunningham wrote:

> I would suggest you install Xcode 8.2.1 to match the buildbots.
> 
> 
> Don’t forget that in almost all cases, MacPorts will use the SDK installed in “/“ when building software. That SDK is the 10.11 SDK, so it is the one that matches your system, and is the one you want. Virtually all standard “open source software” will use that SDK in “/“ on that system.
> 
> The only time that the SDK in Xcode (or the CLTs) is used is if certain software, usually building with Xcode, forces that SDK to be used over the objections of MacPorts (eg qt5, clang’s compiler_rt, etc).
> 
> But - I submit - in those cases, you are likely to be OK, because that software more than likely “knows what to do”.
> 
> 
> So - for maximum happiness, and maximum compatibility, I suggest you duplicate the BuildBot setup we use as a reference platform, and install Xcode 8.2.1 like Ryan did.
> 
> 
> I can’t see that I am going to change the already very complicated Portfiles that we set up to build clang-11 all the way back to 10.6 (and some clangs earlier) for what are non-reference systems.
> 
> It sounds simple to add: 
> 
> compiler.thread_local_storage yes
> 
> but it is just not true that that compiler is always needed. That line in MacPorts forces a whole chain of events that we don’t want to rehash, with very unpredictable results. For example, clang-8.0 builds perfectly well on MacOSX 10.6 using a compiler that does not support thread_local storage, because we have worked around that to match the buildbot reference platform.
> 
> So — we already go to great lengths to support older systems, but I don’t think it’s too much to ask that users set up their older systems in a consistent way to the buildbots we have.

I would consider it unreasonable to ask users to be aware of the existence of our buildbot infrastructure or what versions of Xcode we have installed on the buildbot workers and to ask them to duplicate it.

I didn't mention that I have Xcode 8.2.1 on the 10.11 buildbot worker in order to suggest that the user should duplicate it. Rather I mentioned it as a way to explain why we could build it and he currently cannot.

Users should feel free to install any version of Xcode that is compatible with their OS version. Most users will probably choose the latest compatible version.

It is fine if not all ports can be built with all Xcode versions, though where possible we should accommodate any compatible Xcode version, such as by using the compiler_blacklist_versions portgroup to blacklist incompatible Xcode clang versions or helpers like compiler.thread_local_storage that abstract away the knowledge of which clang versions support which features. As a last resort, a port could print an error if it cannot build with the currently installed Xcode and could advise the user on which version would be acceptable. I created the xcodeversion portgroup to help you emit such an error message.

I'm not sure what you mean by "compiler.thread_local_storage yes" being "unpredictable". It should very predictably restrict the list of acceptable compilers to those that support thread-local storage, with the exception of the bug that currently exists when compiler.cxx_standard is set greater than 2011 which will be fixed in the next version of MacPorts. If you do not require thread-local storage on 10.6, then you can enclose the directive in a conditional that excludes 10.6.

Note that having Xcode 8.2.1 on the 10.11 buildbot worker makes it unusual among our workers. On most of the other workers, I deliberately do not update to the latest Xcode because I want to keep a version of Xcode that contains the SDK matching the OS version. There is value in that strategy because it avoids a whole host of problems relating to weak symbols, which Josh has mentioned before. One example of that kind of problem is just being discussed in https://trac.macports.org/ticket/62278.