[MacPorts] #46493: Update: cmake 3.1.0

[MacPorts]

#46493: Update: cmake 3.1.0
-----------------------------+----------------------
  Reporter:  mschamschula@…  |      Owner:  css@…
      Type:  update          |     Status:  new
  Priority:  Normal          |  Milestone:
 Component:  ports           |    Version:
Resolution:                  |   Keywords:  haspatch
      Port:  cmake           |
-----------------------------+----------------------

Comment (by mojca@…):

 René: I didn't test the Qt4 vs Qt5 yet, but it's nice that you figured it
 out. However the patch seems a bit suboptimal. I'm copy-pasting it here:
 {{{
 variant gui description {Qt based cmake-gui} {
     if {[variant_isset qt4]} {
         # qt4 being requested we have to make sure CMake doesn't detect
 and use
         # qt5 if that happens to be installed too:
         patchfiles-append   patch-CMakeLists.txt.diff \
                             patch-CMakeLists-4qt4.diff
     } else {
         # this is how cmake checks what Qt version to use:
         if {[file exists ${prefix}/lib/pkgconfig/Qt5Widgets.pc]} {
             PortGroup qt5 1.0
         } else {
             PortGroup qt4 1.0
         }
         patchfiles-append   patch-CMakeLists.txt.diff
     }
 }
 }}}
 The problem is that user trying to install `cmake +gui` would still end up
 linking against `qt4`, but the variant `qt4` won't be enabled.

 How about using `qt4` and `qt5` as option names (either keeping or
 dropping `gui`; if kept, `+gui` would automatically enable one of the two
 `qt` options; on the other hand the option `gui` wouldn't really make any
 difference, so it could just as well be dropped)? I would suggest to try
 to decide what variants should be used and then improve the patch a bit to
 make it work "consistently".

 Michael, thanks a lot for stepping forward. CMake is one of the essential
 ports for many packages, so it would be great to have someone who can help
 him keep the port up to date. (I would have volunteered earlier if the
 port was unmaintained, but the maintainer showed up every now and then.)

 Did Chris ever respond? It's also true that he didn't object the addition
 of a new maintainer, but I'm curious if he explicitly agreed. (Most
 commits in the last two years were done as "maintainer timeout".)

-- 
Ticket URL: <https://trac.macports.org/ticket/46493#comment:23>
MacPorts <https://www.macports.org/>
Ports system for OS X