[MacPorts] #15712: Add versions to platforms

MacPorts noreply at macports.org
Fri Apr 13 05:21:04 UTC 2018


#15712: Add versions to platforms
--------------------------+----------------------------
  Reporter:  raimue       |      Owner:  larryv
      Type:  enhancement  |     Status:  assigned
  Priority:  Normal       |  Milestone:  MacPorts 2.6.0
 Component:  base         |    Version:
Resolution:               |   Keywords:
      Port:               |
--------------------------+----------------------------

Comment (by mojca):

 Just to "defend" myself a bit. My "frustration" with blacklisting comes
 from the compiler background. Assume port `foo` which cannot be built with
 the latest compiler & macOS 10.13, providing two non-conflicting
 variantes, `+qt5` (or `+qt4`) and `+wxwidgets`. This particular port would
 generally only blacklist that particular compiler and specify that it
 cannot be built on 10.13.

 Both `qt5-base` and `wxWidgets` have their own set of defunct compilers
 and unsupported macOS versions.

 Now, `wxWidgets` gets upgraded to a newer version after which it no longer
 compiles with `clang 425`. This means that `foo` and all other ports
 depending on `wxWidgets` need to have an additional compiler blacklisted.
 This information does not proliferate from one port to another (from
 dependencies), so all the compiler blacklisting needs to be done inside
 the PortGroup. At the moment we would have three compiler blacklistings:
 for `foo`, for `wxWidgets` and for `qt5`. Only compilers (and OSes) that
 have not been blacklisted anywhere should "survive" after both PortGroups
 have been included.

 I initially failed to realize that blacklisting OS versions can be done in
 an easier way since the system should be designed in a way that will not
 allow installing any port that depends on something that's not supported
 on this platform. That is: it's not necessary to blacklist OSes inside the
 `wxWidgets` PortGroup.

 But I do imagine that there will be still be some PortGroups that will
 require blacklisting OSes, `cxx11` comes to mind as one (not 100% real)
 potential example. If we did not have this sophisticated machinery to
 allow building ports with C++11 on < 10.9, we would specify in the `cxx11`
 PortGroup that those ports cannot be built on `{darwin < 13}`. Now imagine
 a port that needs C++11 and cannot be built on 10.13. My approach would be
 to only specify
 {{{
 platforms {darwin < 17}
 }}}
 or
 {{{
 platforms-blacklist {darwin >= 17}
 }}}
 in the port itself, and leave blacklisting of `{darwin < 13}` to the
 PortGroup.

 I still believe that blacklisting is easier to implement and easier to
 understand than if you specify `{darwin < 17}` in the port and `{darwin >=
 13}` in the PortGroup if that should mean only darwin 13 up to 16.

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


More information about the macports-tickets mailing list