get clang 3.4 and 3.9 4.0 5.0"back"

[rmottola (Riccardo)]

recently clang 8.0 has been marked a replacement for older compilers. This is not true generally: when Mac SDK code is used, too new compilers cause issues, so on 10.6 Snow Leopard, for example 3.9 is a very good compromise, as is clang 5.0 too. Clang 8.0 is just "too new". For non-Mac code this is different and newer compilers are fine (Same applies for GCC, btw, using gcc6 or gcc8 causes issues!)

Ken maybe has more experience, but I think 3.9 is useful to retain. Also, it is difficult to bootstrap these compilers, so to get 8.0 I needed 3.9, but I needed to get 3.4 which is the "source". Similar experiences on 10.7 or 10.5, just with different limits. On 10.5 I use 3.4 and 3.7, wanting to get 3.9 and 5.0 actually

[kencu (Ken)]

We kept 3.4, 3.7, and 5.0 as stepping stones. I hope I thought that through fully...I think that’s the minimal amount needed.

I have kept them all in backup in case we need them, esp 3.9 , but the portfiles will start breaking due to dep changes and base changes sooner or later.

[ryandesign (Ryan Carsten Schmidt)]

See also #58747.

[rmottola (Riccardo)]

4.0 was a bad release for me, no need to get it back. 3.9 did all what 3.7 did, I only don't know if 3.7 is a needed stepstone to actually get a working 3.9? I think to remember yes.

[kencu (Ken)]

Yes, you needed 3.7 to get to 3.9. 3.4 wouldn't build it properly.

If you need 3.9 for some reason, it's easy enough to get it back. You most likely still have it installed. Try sudo port -v activate llvm-3.9 and it should pop up a list of the ones you have. Select the previous-to-last one. Then do the same with clang-3.9 and you'll be good to go.

The only issue will be if the underpinnnings every change requiring a rebuild -- I think this is unlikely to happen, but if it did, then you'd need a portfile to match that version. That is a bit more tricky.

To do that, you create a local repository <​https://guide.macports.org/chunked/development.local-repositories.html> and then find and copy over the last version of the llvm-3.9 directory that you want.

You can find this pretty easily by looking at the log history in the git repo.

[jeremyhu (Jeremy Huddleston Sequoia)]

What specific issues are you seeing clang-8.0 have with the SnowLeopard SDK? I am not aware of any issues. This ticket is not really actionable without specifics. We won't be resurrecting 3.9 nor 4.0.

[jeremyhu (Jeremy Huddleston Sequoia)]

Also, I'm not aware of 5.0 being needed for bootstrapping later builds anywhere. Where is that information coming from? I'd like to also deprecate 5.0 and 6.0 next year.

[kencu (Ken)]

I haven’t verified building clang 7+ with clang 3.7 as yet.

It might work ; just don’t know for sure at present.

[cjones051073 (Chris Jones)]

Obsoleting macports clang compilers is fine, I am in favour of removing old ones as possible, but before obsoleting the port you first need to remove reference to them in base. A number of them are used as fallbacks and this needs to be removed, *and* made available to users as a public release, *before* the port is declared obsolete. e.g. Macports clang 5.0 is a very commonly used fallback, so please do not obsolete this one at least before removing all references to it in base. I recently had to do this for 3.9 and 4.0 in base, which should have been done before the ports themselves where declared as obsolete.

​https://github.com/macports/macports-base/pull/137

[jmroot (Joshua Root)]

Yeah, these need to come back until after the next base release.

[jmroot (Joshua Root)]

In 499729eaf92d6c7cf9a697575c9f5f2233315982/macports-ports (master):

Revert "llvm-3.9: Obsolete port" and "llvm-4.0: Obsolete port"

This reverts commits 8470ccfcdae5c31638c4c5bc2b24ee05e4a2a95b and
7615202b212d36d0598b5775cb33020a916462ac.

These clang versions are in the default fallback list used by base,
and so need to remain available until after a new base version that
doesn't use them is released.

Fixes: #58741

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jmroot:

Yeah, these need to come back until after the next base release.

Why? They aren't referenced in base any more? That logic has been kept in the ports tree for almost a year now, and it was updated prior to the obsoletion.

[jmroot (Joshua Root)]

Yes, it's been too long between releases. 2.5.x doesn't use the compiler selection files in the ports tree.

​https://github.com/macports/macports-base/blob/v2.5.4/src/port1.0/portconfigure.tcl#L604

[cjones051073 (Chris Jones)]

I can only agree, we really should think about making incremental base releases a bit more regularly... Its been way too long since the last.