Hail, Your feedback goes beyond my expectations. Before I follow this further, here is a summary of my installation attempt as Marcus requested. I hope that it is a good balance between detail and clutter.
First to clarify, by 'local' I mean under my home directory (no superuser install). The OS is opensuse Leap 15.4. The required Type.h and Types.hpp are in the directory: > ls ~/.local/include gnuradio lime pmt SoapySDR The sequence of the installation is as follows: (1) gnuradio 3.10.5.1 was installed in the usual manner from the cloned repository. gnuradio/build> cmake -DCMAKE_INSTALL_PREFIX=~/.local -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 -DBoost_LIBRARY_DIRS=/usr/lib64 -DQWT_LIBRARIES=/usr/lib64/libqwt.so.6 -DQWT_INCLUDE_DIRS=/usr/include/qt5/qwt6 -DENABLE_GR_UHD=OFF -DZEROMQ_LIBRARIES=/usr/local/lib64/libzmq.so -DZEROMQ_INCLUDE_DIRS=/usr/local/include -DENABLE_GR_SOAPY=OFF ../ Environment variables: LD_LIBRARY_PATH="~/.local/lib" PYTHONPATH="~/.local/lib64/python3.6/site-packages" The installation worked as expected. (2) The distro version of soapySDR (branch 0.8) was NOT installed as per the recommendation of https://wiki.gnuradio.org/index.php/Soapy#gr-osmosdr%20(Ref:%20https://github.com/pothosware/SoapySDR/wiki/BuildGuide SoapySDR-soapy-sdr-0.7.2 was built and installed from a downloaded archive file. SoapySDR-soapy-sdr-0.7.2/build> cmake -DCMAKE_INSTALL_PREFIX:PATH=~/.local -DENABLE_PYTHON3=OFF Executing SoapySDRUtil worked as expected. (3) LimeSuite 20.10.0 built and installed from downloaded archive file. LimeSuite-20.10.0/builddir> cmake -DCMAKE_INSTALL_PREFIX:PATH=~/.local -DENABLE_GUI=ON -DENABLE_UTILITIES=ON -DENABLE_SOAPY_LMS7=ON ../ Executing SoapySDRUtil and LimeUtil found hardware and reported as expected. (4) gnuradio build directory was emptied and CMakeCache.txt deleted. gnuradio/build> cmake -DCMAKE_INSTALL_PREFIX=~/.local -DCMAKE_BUILD_TYPE=Release -DPYTHON_EXECUTABLE=/usr/bin/python3 -DBoost_LIBRARY_DIRS=/usr/lib64 -DQWT_LIBRARIES=/usr/lib64/libqwt.so.6 -DQWT_INCLUDE_DIRS=/usr/include/qt5/qwt6 -DENABLE_GR_UHD=OFF -DZEROMQ_LIBRARIES=/usr/local/lib64/libzmq.so -DZEROMQ_INCLUDE_DIRS=/usr/local/include -DENABLE_GR_SOAPY=ON ../ Configuration by cmake did not show errors but gnuradio/build> make -j4 results in error on missing <SoapySDR/Types.hpp> as mentioned below. More details upon request. cheers, Rick On 2023-02-07 10:48, Ryan Volz wrote: > Hi all, > > GNU Radio's cmake scripts do check for this situation (SoapySDR not > found, GR_ENABLE_SOAPY force-enabled) and it should error out when > `cmake` is run: > > https://github.com/gnuradio/gnuradio/blob/main/cmake/Modules/GrComponent.cmake#L71 > > The full CMake output would be useful to figuring out why that didn't > happen. As far as I can tell, CMake should not "find" SoapySDR if its > headers are missing, but maybe that's where it is going wrong. > > Cheers, > Ryan > > On 2/7/23 5:14 AM, Marcus Müller wrote: >> Hi Ron, Hi Rick, >> >> agreed, you probably need that development package. Problem: Without it, >> the GNU Radio build infrastructure shouldn't even allow for enabling of >> the SoapySDR components. >> >> So, Rick, could you tell us which operating system/distro this is on, >> and how you did that local installation of SoapySDR, precisely? >> >> Best regards, >> Marcus >> >> On 07.02.23 06:19, Ron Economos wrote: >>> You probably need the development package. >>> >>> sudo apt-get install libsoapysdr-dev >>> >>> Ron >>> >>> On 2/6/23 18:37, aardric wrote: >>>> I executed the following steps which I think are consistent with >>>> documentation on the wiki. >>>> >>>> (1) local installation of SoapySDR 0.7.2 appears to work. >>>> (2) build and local install of gnuradio 3.10.5.1 works as expected with >>>> -DENABLE_GR_SOAPY=OFF >>>> (3) delete the gnuradio/build folder and run cmake with >>>> -DENABLE_GR_SOAPY=ON configures without an obvious problem. >>>> (4) however, make fails with: >>>> include/gnuradio/soapy/soapy_types.h:15:10: fatal error: >>>> SoapySDR/Types.hpp: No such file or directory >>>> 15 | #include <SoapySDR/Types.hpp> >>>> >>>> I'm hoping to get advice on whether the above procedure was reasonable >>>> before I (as a non developer) attempts to reverse engineer and debug the >>>> above process. I hesitate to raise an issue for something which may be >>>> obvious or a problem with my particular installation. >>>> >>>> Rick >>>> >>>> >>>> >>> >>