search

jgaeddert / liquid-dsp

digital signal processing library for software-defined radios
http://liquidsdr.org
MIT License
1.87k stars 439 forks source link

CMake Build Support for liquid 1.5.0 #314

Open lukeprince20 opened 1 year ago

lukeprince20 commented 1 year ago

Current minimum version set to CMake 3.15 to take advantage of newer language features. Alternative to using autotools for building liquid. The contribution is purely additive and does not modify the autotools configuration or impact the current behavior/performance of liquid when built the conventional way. This is a 1-to-1 port of configure.ac and makefile.in to CMakeLists.txt + supporting CMake module files. Certain options such as the default CFLAGS are left up to the CMake generator to determine (e.g. If you want -g -O2 then you do a RelWithDebInfo build). Handles the required platform checks for generating config.h. Depends on the cpu_features library for detection of supported CPU instruction sets. All main targets defined by makefile.in are supported. The help target has been rebranded as list due to help being reserved by the CMake Unix Makefile generator. The .gitignore has been updated to handle CMake generated build files.

Note that not all generated executables currently write to the build folder, but continue to be created in their expected locations within the source. This is to ensure the correct results are output when running targets that depend on the autoscript generated xautotest/benchmark programs. Additionally the examples and sandbox executables are also still written to their expected locations within the source. The clean targets still work as expected.

Building with CMake is a prerequisite for introducing MSVC support. However, the Microsoft Visual Studio C Compiler is not fully compatible with the C99 standard. It does not support the complex/_Complex keywords or variable-length arrays, both of which are optional C11 features. These are currently required for compilation. I plan to address these in upcoming PRs with the goal of removing the need for MSYS2/MinGW and addressing other issues summarized in https://github.com/jgaeddert/liquid-dsp/issues/209#issuecomment-673438743.

Credit where it's due: I built upon the prior work of @brian-armstrong in https://github.com/quiet/quiet-dsp/tree/win as a guide for the general layout of my CMakeLists.txt. This PR can be considered a resurrection of his work for the latest version of liquid, albeit without MSVC support. See https://github.com/jgaeddert/liquid-dsp/issues/102 and https://github.com/jgaeddert/liquid-dsp/issues/209#issuecomment-745073771.

This PR supersedes https://github.com/jgaeddert/liquid-dsp/pull/40 which has staled.

pfeatherstone commented 1 year ago

You can use target_sources() rather than having variables for different source lists.

lukeprince20 commented 1 year ago

I used variables as I was closely following the layout of the makefile.in to ease comparison. I liked the aesthetic of keeping the library, autotest, and benchmark sources grouped together. I suppose I could have also taken an object library approach as well. I'm open to changing it now or later if it positively impacts the build. Currently, the compile commands produced by the build closely mirror those in the autotools generated makefile which was my main objective.

pfeatherstone commented 1 year ago

I would use cmake best practices rather than make it mirror autotools. Not saying you don't but may as well use the functions cmake provides out the box.

pfeatherstone commented 1 year ago

I would use https://cmake.org/cmake/help/latest/module/CMakeDependentOption.html for options that depend on libraries like FFTW.

pfeatherstone commented 11 months ago

Should we not revive cmake support? It's way better than autotools, cross platform and you can integrate into other projects quite easily using FetchContent. @jgaeddert