Host software CMake cleanup: attempt #2

[multiplemonomials]

Apologies for the issues that were encountered with the first version of my PR (#664), turns out that this build system was supposed to operate in ways I wasn't aware of. I went through all the feedback and made adjustments, and I believe I addressed all the issues with the original version. Summary of changes made:

• Fixed SOVERSION bug, SOVERSION has 3 digits again
• Adjusted build system to handle being run from all three possible top dirs: host/, host/hackrf-tools/, and host/libhackrf/
  • Moved common logic (compile flags, common dependencies, etc) into a script that is called from wherever the top directory is
  • Added back FindLIBHACKRF module (used by a standalone tools build to locate libhackrf) and improved it to better handle static libraries and Windows builds
• Fixed some incorrect library install dirs

To see the full set of changes vs the original PR, just look at all commits after the first commit in this PR.

To make sure things were working, I ran builds this PR on Windows MinGW, Windows MSVC, and Ubuntu. For each environment, I tried a build from each of the three supported top directories. I'm fairly confident that it should be working the way you want it now!

[mossmann]

Thank you so much for taking the time to work on this! We will review it soon.

[multiplemonomials]

Had a chance to look at this yet?

[mossmann]

I'm planning to make a release shortly and then review and merge this PR right after the release.

[multiplemonomials]

@mossmann Pinging again one year later, I rebased this to be compatible with latest master branch. Everything look ok to merge?

I also updated the new github actions windows job to be compatible with this MR. Now, it uses CMAKE_PREFIX_PATH to pick up everything that vcpkg installs in one single swoop. To make this work, I had to update the library names searched for by the pthread and libusb find modules to match what vcpkg installs.

Last but not least, I'm seeing something odd where my local clang-format and the CI job are disagreeing about how to format one specific block of code (#define true 1). So running the clang format script does not generate code that passes the CI.

[straithe]

Thank you for updating this PR again! We really appreciate your patience.

Our team is stretched very thin and will continue to be for a while. I'll do my best to see if I can get some community reviews and free up some time from the reviewers within GSG.

[multiplemonomials]

@straithe any updates?

[straithe]

I don't have the skillset to review this particularly well myself and the senior reviewers on my team are booked up for a couple months. I've asked in the GSG Discord for community reviews so I can ensure this solution works for a variety of systems.

[jLynx]

I tried building this, it was successful for windows, but the exe's didn't actually work for whatever reason. any thoughts @multiplemonomials ?

[multiplemonomials]

What exactly didn't work? Did they fail to run? If so, that can be cause by having missing or incorrect DLLs in your system PATH. I recommend using Dependencies to load the executables and see what DLLs they are trying to load.

[jLynx]

@multiplemonomials you can download the artifacts here to try run it https://github.com/jLynx/hackrf/actions/runs/5151822083

And here is the workflow file https://github.com/jLynx/hackrf/actions/runs/5151822083/workflow

And when I said it didn't run, i mean when I called the exe via cli, nothing was outputted, so errors, nothing. -h didn't return anything either

[multiplemonomials]

Ah, I think the issue is that the artifacts don't include libhackrf.dll, which is necessary to run the executables. (they don't include the fftw dll either, which is needed for hackrf_sweep).

You can see this by running Dependencies on the executables:

I'm not a github actions expert, but I think the artifacts need to include the ${{runner.workspace}}/host/libhackrf/build folder as well, which will contain the DLL.

[jLynx]

Do the dll's get updated too, or are the the same ones from a few years ago? The reason I ask is because I copied some old ones in the dir to test and it didn't work. But I'm assuming they did get updated and that's the reason why @multiplemonomials

[multiplemonomials]

Most likely, yeah.

[dmaltsiniotis]

Do the dll's get updated too, or are the the same ones from a few years ago? The reason I ask is because I copied some old ones in the dir to test and it didn't work. But I'm assuming they did get updated and that's the reason why @multiplemonomials

As far as I know, the same dependency DLL are used. These versions are the ones I use when building the latest host software on Windows and need to be included for libhackrf to operate:

fftw-3.3.5-dll64
libusb-1.0.24
pthreads-w32-2-9-1-release

[mossmann]

@multiplemonomials Is there is a reason that cmake version 3.8 is required for this?

[multiplemonomials]

Yes, I believe that it does use some CMake 3.8 specific features. But 3.8 should be available on any modern linux distro at this point, it's a years old release.

btw, want me to rebaae this MR?

[LecrisUT]

Please include(GNUInstallDirs) and remove these DESTINATION (equivalent to using the CMAKE_INSTALL_* variables)

[multiplemonomials]

Will do, I can update this! Is this PR intended to be merged once I make the update?

[maitbot]

Now I find this issue...
I did some refactoring:
maitbot@605c449

(not yet a pull request - especially since I see this issue I'm commenting in.)

ci-scripts:
Update cmake useage, skip mkdir step, use cmake instead of make.

host:
Update cmake_minimum_required.
(GNU Radio picked 3.16, because Ubuntu 20.04 used 3.16.3, and that is
now more than 5 years ago.)

Update project() call.
CMake project handles VERSION now too.
Defines PROJECT_VERSION and PROJECT_VERSION_MAJOR etc., which will be used
to set CMake library target properties for VERSION and SOVERSION.

Add some overall build defaults,
set(CMAKE_VERBOSE_MAKEFILE ON)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)
These settings help to not hide details from the build logs, and
editors using LSP will want to consume the generated compile_commands.json file.
(vim can use LSP with clangd, and emacs has LSP and eglot modes.)

Make use of CMake's GNUInstallDirs.
Smart way to set install DESTINATIONs.
Update all DESTINATION to use GNUInstallDirs variables.
(except MSVC builds - someone else want to change this?)

Just use CMake's FindThreads.
Since CMake 3.1 it handles PTHREADS and sets
CMAKE_USE_WIN32_THREADS_INIT for Windows builds.
Use the Threads::Threads CMake target.
Remove cmake/modules/FindThreads.cmake

Rename FindUSB1 to FindLIBUSB, and have it provide the
LIBUSB::LIBUSB CMake target. (This also avoids warnings about
confusion between LIBUSB vs USB1 definitions.)

libhackrf:
Remove c_sources and c_headers CMake variables, they just add a
potentially confusing layer of indirection. Just be explicit when
referencing source files.

See CMake documentation for cmake-packages(7)
Install CMake Config-file package files for users.
Maybe include(GenerateExportHeader)? Added in version 3.12: Added
support for C projects. Previous versions supported C++ project only.
Are paths and case good for HackRF/HackRFConfig.cmake?

hackrf-tools:
Use FindFFTW3.cmake from GNU Radio instead of FindFFTW and use the
modern CMake target fftw3f::fftw3f it provides.

Build with Modern CMake targets.

Check to ensure project build with both Makefile and Ninja generators.

TODO: check Windows build
I have done no Windows build, and I'd like help with that.

I haven't looked at multiplemonomials branch yet.
Just putting it out there that I have dome some CMake "modernization" that provides
CMake package Config files along with the library.

73 de aa4hs,
-Maitland