[MacPorts] #44237: CMake @3.0.0_2: configure and build pick up local frameworks

[MacPorts]

#44237: CMake @3.0.0_2: configure and build pick up local frameworks
------------------------------+-------------------
  Reporter:  luc_j_bourhis@…  |      Owner:  css@…
      Type:  defect           |     Status:  new
  Priority:  Normal           |  Milestone:
 Component:  ports            |    Version:
Resolution:                   |   Keywords:
      Port:  cmake            |
------------------------------+-------------------

Comment (by mojca@…):

 The upstream bug report about Gtk.framework has been closed as "unable to
 reproduce":
   * http://cmake.org/Bug/view.php?id=15027
 (I agree that it was probably difficult to figure out how to reproduce it,
 but I don't agree with not doing anything to fix that specific problem.)

 In a way CMake is somewhat "broken by design" when it comes to searching
 the libraries on Mac in a way that wouldn't interfere with MP.

 in #45846 yannis mentioned the existence of the following libraries:

 {{{
 libMagick++.framework
 libMagick.framework
 libWand.framework
 libbz2.framework
 libcharset.framework
 libcurl.framework
 libiconv.framework
 libjasper.framework
 libjpeg.framework
 libpng.framework
 libtiff.framework
 libxml2.framework
 libz.framework
 }}}

 Any single one of them could cause problems and every single problematic
 one should be fixed separately.

 I would start hunting for the sloppy mac installer that has put all those
 libraries there and try to convince them to fix the installer.

 I don't know if there is any way to prevent searching for libraries inside
 /Library/Frameworks on a "global level". I'm afraid that every CMake
 module would need to be fixed separately. And it might get difficult to
 fix them. (CMake developers probably want to keep supporting searching for
 frameworks in /Library/Frameworks.)

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