[MacPorts] #53201: cmake: doesn't recognize macports-clang (No known features for CXX compiler)

[MacPorts]

#53201: cmake: doesn't recognize macports-clang (No known features for CXX
compiler)
---------------------+-----------------------
  Reporter:  RJVB    |      Owner:  michaelld
      Type:  defect  |     Status:  assigned
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:
Resolution:          |   Keywords:
      Port:  cmake   |
---------------------+-----------------------

Comment (by RJVB):

 Mojca voiced a concern on the ML that my patch could lead to mis-
 identification of features of the system AppleClang compiler.

 I found an equivalence table of sorts:
 https://gist.github.com/yamaya/2924292

 which I can complete with

 Xcode 3.2.6:
 {{{
 > /Developer/usr/bin/clang --version
 Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn)
 }}}

 and Xcode 4.2:

 {{{
 > /usr/bin/clang --version
 Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
 Target: x86_64-apple-darwin13.4.0
 }}}

 (both are identified as regular Clang by CMake, v1.7 and v3.0.0
 respectively)

 Indeed, such issues could occur with AppleClang versions based on Clang
 3.4 and earlier. Clang 3.5 and later are fine as the corresponding
 AppleClang have version 6 and up in CMake.

 However, it looks like indeed the compilers provided by Xcode >= 4.4
 (AppleClang 4.x) and < 6.0 (AppleClang 5.1.x) will be identified as a more
 recent compilers and thus endowed with features they don't have.

 The linked table also shows that setting up an equivalence table in CMake
 script code will be more complicated than it should be if we don't figure
 out where CMake generates its AppleClang version strings from what the
 compiler returns ("6.0.0.6000057" for "Apple LLVM version 6.0
 (clang-600.0.57) (based on LLVM 3.5svn)").

 We'd still need to do something like this (using the "(based on LLVM
 x.y*)" string?) if we want to get a patch upstreamed, but we could also be
 consider that we're approaching this from the wrong side for MacPorts
 purposes. The easy way out here would be to patch the clang ports such
 that they spoof the corresponding AppleClang version string. As I said,
 that would only be necessary for clang 3.4 and below, and could be
 reserved for when the port is to provide the MacPorts default compiler.
 If someone could add Jeremy and/or Larry to this ticket, they might have
 feedback on this.

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