Cmake module issue

I received a report this morning that gr-osmosdr was not configuring
correctly in MacPorts; not able to find GNU Radio. Trying this myself,
I can recreate the issue. After some investigation, the issue is
somewhere between a cmake bug, and GR issue, and “my bad”. I’ve read
through the cmake documents on this topic as well as tried what cmake
printed as its error message, but none of those make sense or work. I
can work around the issue, but I think there needs to be better
integration between GR and cmake.

What happened is that yesterday (Tuesday, 15-Oct-2013) I pushed a change
which moved the GR cmake files from their default install location,
${prefix}/lib/cmake, to a common (across all ports) cmake location:
${prefix}/share/cmake/modules/. After install, I moved
${prefix}/lib/cmake/* into ${prefix}/share/cmake/modules/ -> which means
there are 2 directories now: gnuradio and volk. I thought that this is
the way cmake should like things, and I know it is the way MacPorts
prefers non-cmake-provided cmake modules to be installed.

But, cmake does not like this setup; it cannot find GR using this setup.
After testing a bunch, I find that there are 2 configurations cmake

  1. having “FindGnuradio.cmake” in a directory in CMAKE_MODULE_PATH
    (whether as an actual file or linked).

  2. having “GnuradioConfig.cmake” in a top-level directory in some other
    cmake search path – I don’t have a variable name for this one, but it
    seems to include “${prefix}/lib/cmake:${prefix}/share/cmake”, where the
    “cmake-X.Y” is installed (and known) by cmake itself; seems like it is
    like each value in CMAKE_MODULE_PATH but with “[Mm]odules” removed from
    the end.

GR provides just GnuradioConfig.cmake, not FindGnuradio.cmake. Hence, I
have to place the “gnuradio” directory in a top-level directory, not in
a modules directory. It also seems to work that I can link
GnuradioConfig.cmake to FindGnuradio.cmake so long as this link is in a
directory in CMAKE_MODULE_PATH.

So … I’m not sure what to make of this behavior by cmake. I will fix
the way these files are installed within MacPorts, for now, but I hope
we come up with a better solution. - MLD