Opened 5 years ago
Closed 5 years ago
#60108 closed update (fixed)
clang-devel is outdated.
| Reported by: | marka63 | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | |
| Keywords: | Cc: | larryv (Lawrence Velázquez), kencu (Ken) | |
| Port: | clang-devel |
Description
clang development upstream is clang-11.0 the current clang-devel (9.0.0) is behind clang-9.0 (9.0.1)
I was trying to use clang-format with style files developed for clang-format-11.0 (on Unbutu) and neither the release versions nor the development versions worked.
Change History (6)
comment:1 Changed 5 years ago by jmroot (Joshua Root)
| Cc: | larryv kencu added |
|---|---|
| Owner: | set to jeremyhu |
| Status: | new → assigned |
comment:2 Changed 5 years ago by kencu (Ken)
comment:3 Changed 5 years ago by jeremyhu (Jeremy Huddleston Sequoia)
You're right that it will be a lot of work, but I have faith that you'll be able to handle it. Unfortunately, my day job (Apple) and my night job (Daddy) are taking up 200% of my time these days. Just be patient with yourself, and work through issues as they come up methodically. If you run into anything that looks odd and you want me to take a look, just shoot me an email. I'll try to be responsive.
comment:4 Changed 5 years ago by kencu (Ken)
It looks like the module support in c++20 for clang in MacPorts will be broken until <https://trac.macports.org/ticket/59992> is resolved. An upstream fix for the module issue is no doubt to be found in due course.
As this is a core c++20 feature, I'm not sure how to proceed. Hacking in fixes and workarounds to cover up the real problem is generally speaking a bad idea. I have tweaked my own ${prefix}/include/unctrl.h in our ncurses port to allow modules to "work" pending the upstream fix.
Perhaps there is some fancy way this can be worked around. If I'm feeling brave enough, I'll ask on the clang-devel list.
comment:5 Changed 5 years ago by kencu (Ken)
FYi, clang-10. has been released <https://releases.llvm.org/download.html#10.0.0> as of this week.
comment:6 Changed 5 years ago by kencu (Ken)
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
the previous
llvmsvnaccess is now dead and gone, as I trust a good many of you might already know. The*-develversions ofllvm,clang, andlldbwill therefore need a wholesale reconfiguration.It's probably time to build them all directly from the monorepo, all at once.
We should now start to do the two-stage build as well, so we are not using a crippled clang/llvm setup built with the ancient clang-3.7 or something of a similar ilk.
I received an email from the
libc++lead indicating their new floor for buildinglibc++will soon be 10.12, and that has to be built as part of llvm/clang at present, so that will need a workaround using parts oflegacysupportI think, or at least borrowing thegettimeimplementation from there to get the build going.And finally, as part of this
clang-10(orclang-10.0) is here, and we have to sort out properly the name change frommacports-clang-N.0tomacports-clang-N, which sound trivial, but is unlikely to be so given how many ports I have seen that have tweaked compiler blacklisting based on certain tcl structures like:compiler.blacklist-append {macports-clang-[3-8].0}and such.Jeremy will possibly want to be involved in such a wholesale reconfiguration -- he's very busy these days. It will need plenty of testing.
Long story short -- this will take some time.