restrictive patch to CMake's find frameworks algorithm

[RJVB (René Bertin)]

I think the patch to patch-CMakeFindFrameworks.cmake.diff has become too restrictive by *replacing* the search location /usr/local/Frameworks with MacPorts's own frameworks install dir.

This would be fine if CMake were used exclusively for building by MacPorts and/or for building software targetting $prefix and depending only on software under that location. But CMake is a build tool that users might use to build software targetting other locations (they should, in fact) and depending on software not installed through MacPorts.

Older versions of this patch simply added the MacPorts location ahead of the /usr/local location and that should still be a sufficient solution that does not break the aforementioned kind of builds.

[ryandesign (Ryan Carsten Schmidt)]

See the extensive previous discussion of this issue here:

​https://github.com/macports/macports-ports/pull/7797

The conclusion of the discussion was that /usr/local/Frameworks is not a standard location for frameworks to be installed. (The standard location would be /Library/Frameworks.) Only Homebrew installs frameworks in /usr/local/Frameworks. As such, we are ok with removing it, since a user who wants to find Homebrew-installed frameworks should be using a cmake installed by Homebrew, not one installed by MacPorts.

[RJVB (René Bertin)]

Replying to ryandesign:

Only Homebrew installs frameworks in /usr/local/Frameworks.

If that was the well-founded conclusion of the linked discussion (which I haven't had time to scan through) then I suppose it's less dramatic than I thought to remove the path. But I'm not so easily convinced that no "semi-informed" project would install frameworks into a Frameworks directory under its $prefix, nor that there are no users who use /usr/local that way. I know I'd be likely to do that myself (instead, I just "trespass" in $prefix, using porg to keep track of my stuff).

a user who wants to find Homebrew-installed frameworks should be using a cmake installed by Homebrew, not one installed by MacPorts.

I cannot agree with that. Again, CMake is NOT a private tool that shouldn't be used for any other purpose than to build software destined for installation in $prefix or using only dependencies under $prefix. Why would it be made difficult for users who have a HB install in addition to MacPorts because of stuff that's not available in MacPorts?

Now, if /usr/local/Frameworks is in CMakeFindFrameworks.cmake *because* HomeBrew uses that path, then an argument could be made (upstream!) that the search should include $prefix/Framework (I suppose that would be ${CMAKE_SYSTEM_PREFIX_PATH}/Frameworks). Being more generic that should logically come before the hardcoded path, but that could always be corrected in a patchfile.

[michaelld (Michael Dickens)]

These thoughts might be part of the noted PR ... adding them for the sake of completion:

1) We (or at least I) want the defaults for CMake as supplied by MP to search through MP paths first, then system paths.

2) In the case all else fails in (1), we don't want defaults pointing to other locations unless specified within 'port' somehow (the Portfile, a PortGroup, user preferences, etc).

3) The developer using MP CMake can always specify paths for CMake to search that are outside of any from (1). I'm pretty sure with modern CMake these paths can search first or last. Thus with the equivalent of a "CMake portgroup" one can batch-configure projects to all point to the same search directories. Not perfect, but it would work.

[RJVB (René Bertin)]

Replying to michaelld:

1) We (or at least I) want the defaults for CMake as supplied by MP to search through MP paths first, then system paths.

Then you would probably want to remove all but /System/Library/Frameworks (and its /Network equivalent if that exists)!

3) The developer using MP CMake can always specify paths for CMake to search that are outside of any from (1). I'm pretty sure with modern CMake these paths can search first or last. Thus with the equivalent of a "CMake portgroup" one can batch-configure projects to all point to the same search directories. Not perfect, but it would work.

I understand the reasons behind this, but it's still crippling the tool, a bit like if you disallowed an IDE installed through MacPorts from accessing SDKs or toolchains installed independently. A better analogy might be $PATH; imagine if MacPorts would make it hard for you to have /usr/local/bin in your path. The port driver command *could* do that in theory; instead, "base" just sets its own PATH.

It would be perfectly possible (and rather trivial) to patch CMakeFindFrameworks.cmake in such a way that the CMake PortGroup(s) can require a sanitised framework search path. That would be a more correct solution: users would benefit from the extended framework search path that includes $prefix/Frameworks, while port builds are restriced to the "legal minimum" by default.

I've extended CMake functionality before so if there's interest for such a patch it shouldn't take me too long to write and test it. (If so, I'll take suggestions for the name of the control variable as well as what to remove from the search path.)

[cooljeanius (Eric Gallager)]

This seems similar to #44237

[ryandesign (Ryan Carsten Schmidt)]

Replying to RJVB:

users who have a HB install in addition to MacPorts

We have never supported users trying to use more than one package manager on the same system because they interfere with one another and we kindly ask them to uninstall all but one of them.