Re: [MacPorts] #51208: icu @55.1 — add a +norename variant

[MacPorts]

#51208: icu @55.1 — add a +norename variant
-------------------------------+------------------------
  Reporter:  ken.mcglothlen@…  |      Owner:  ryandesign
      Type:  enhancement       |     Status:  closed
  Priority:  Normal            |  Milestone:
 Component:  ports             |    Version:
Resolution:  wontfix           |   Keywords:  haspatch
      Port:  icu               |
-------------------------------+------------------------
Changes (by ryandesign):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 The boost port's "no_single" and "no_static" variant names are a decade or
 more out of date and do not represent our best practices. They should
 really be converted to subports at this point.

 As I understand the situation, icu offers a choice about whether the
 symbols that go into its libraries are suffixed with a version number or
 not. Whichever way we choose, those are the symbols other programs will
 expect to be in the library. If we enable the version number suffix
 feature, I don't think other programs will explicitly use a version number
 suffix, but I think that the icu headers will do so automatically when a
 symbol without the version number suffix is used. As such, I don't think
 it matters to other software whether or not we use this feature.

 Since this choice affects how all other software uses icu, we cannot leave
 it up to the user to change this via a variant. If we did, and the user
 changed it from the default that we use on our build machines, anything
 they had installed via a binary from our build machine would be broken.

 So we have to either always rename symbols, or always not rename symbols.
 And since the default is to rename symbols, and that has been working fine
 for us so far, I see no reason to change it.

 No, disabling symbol renaming would have no bearing on the fact that we
 need to increase the revision of ports that use the library when the major
 version number increases. This is simply the reality of what a major
 version number increase means: it means the library is not backward
 compatible, at least not in terms of ABI. (If it were ABI-compatible, the
 developers would not have increased the major version.) It may be API-
 compatible in that recompiling the other software would be enough, or it
 may be API-incompatible, requiring source code changes in the other
 software. Either way, the library major version number is part of the
 library's filename and install_name, so any other software linking with
 the old library major version number will simply fail at runtime with a
 message that the library file cannot be found. Hence we must revbump to
 rebuild.

-- 
Ticket URL: <https://trac.macports.org/ticket/51208#comment:6>
MacPorts <https://www.macports.org/>
Ports system for macOS