[PATCH] D132486: SONAME introduce option CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION

[H. Vetinari via Phabricator via llvm-commits]

h-vetinari added a comment.

> My concerns have already been raised by others in that thread and related issues, I see no point in restating them yet again. I don't see consensus, I see a handful of people discussing reverting a change that broke a whole bunch of assumptions made by real-world code.

I don't think that's a fair characterization. The release manager (as well as author of bot the original change & the reversion) and the interim release manager discussed this and came to the same conclusion despite being very aware of the complaints. Other than that there was one comment against where the person did not respond to a request for further information & 3 people who were asking to keep the ABI information.



================
Comment at: clang/CMakeLists.txt:467
+option(CLANG_FORCE_MATCHING_LIBCLANG_SOVERSION
+  "Force the SOVERSION of libclang to be equal to CLANG_MAJOR" OFF)
+
----------------
jrtc27 wrote:
> h-vetinari wrote:
> > jrtc27 wrote:
> > > OFF by default changes behaviour, which seems irresponsible so late in the release cycle
> > I disagree. This is the status of the last released version.
> It's the status of the last release candidate, something which downstreams are encouraged to consume early in order to give feedback. If we only need to care about the last released version when making changes then what's the point of having a release branch with policies around what's ok to backport?
This kind of change is a good example why there are release candidates. We raised this shortly after rc2 (I built them as fast as possible, given that limits on public CI means this is a multistep process that can take a bit).


================
Comment at: clang/tools/libclang/CMakeLists.txt:14-17
+# TODO: harmonize usage of LIBCLANG_SOVERSION / LIBCLANG_LIBARY_VERSION
+#       below; this was added under time-pressure to avoid reverting the
+#       better default from LLVM 14 for LLVM 15.0.0-rc3, hence no time
+#       to clean up previous inconsistencies.
----------------
jrtc27 wrote:
> h-vetinari wrote:
> > jrtc27 wrote:
> > > This is highly subjective. Many believe the default was worse due to (a) confusion (b) technical issues when coinstalling multiple LLVM versions. Ping-ponging like this is just creating a mess.
> > The ping pong has not been released yet, and so it's "just" happening as part of the development process so far.
> > 
> > It's subjective how this changes ranks vis-à-vis someone's personal preferences/priorities, but I'd argue it's objectively better from a technical perspective, as it keeps strictly more information as otherwise. On top of that we're solving (b) for those who do not want to make use of this additional information, or are bothered by it.
> Except people package the rc's and get annoyed when major changes like this are made; if we ask for people to test things, then go and revert something significant at the last minute, that's not good practice.
Which is why we're trying to get this into the next/last rc.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D132486/new/

https://reviews.llvm.org/D132486