-
Notifications
You must be signed in to change notification settings - Fork 195
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add cmake support #528
Add cmake support #528
Conversation
@czurnieden I took the liberty to cherry-pick what you already added to this branch and |
096aec2
to
bafc708
Compare
ee3cdbf
to
302d541
Compare
The pkg-config file |
fixes cmake (v3.10.2) error under ubuntu 18.04 due to reserved target name
in addition to be able to pass it on cmake invokation tools like ccmake et al. will show it as a configurable option
Signed-off-by: Steffen Jaeckel <[email protected]>
The test sources must be compiled with a special define and require optimisation in order to be able to run. Signed-off-by: Steffen Jaeckel <[email protected]>
Signed-off-by: Steffen Jaeckel <[email protected]>
* remove some of the complicated logic. The additional warnings always make sense. CMake uses the state of `BUILD_SHARED_LIBS` to determine the library target type. Also remove the comment regarding building shared and static at the same time, as usually that's done as necessary by the user. * append user-defined {C,LD}FLAGS instead of preprending - we expect them to know what they do, so they can override our defaults * use target_{compile,link}_options() instead of setting variables Signed-off-by: Steffen Jaeckel <[email protected]>
Signed-off-by: Steffen Jaeckel <[email protected]>
302d541
to
50678c1
Compare
I'm also not sure if that really makes sense in the CMake context ... I've read through https://gitlab.kitware.com/cmake/community/-/wikis/FAQ#can-i-do-make-uninstall-with-cmake and maybe they are right ... I think a user who wants to install the library on their system should use cpack to package the build and then install it via their package manager. Also there's the package registry which allows all CMake users to use |
* bump to CMake 3.10 * only support the CMake standard way to define variables via `-DFOO=On` and not via the environment * clean-up switches only used for unit tests * mingw's ID is "GNU", so we match on the full compiler name instead * use CMake variables instead of environment variables via `$ENV{<stuff>}` * unconditionally set {C,LD}FLAGS passed by user * clean-up duplicate CPack keys + add FreeBSD config * store pack files in distro-specific paths * use default names where possible * use `CMAKE_BUILD_TYPE`-style variables instead of our own flags * set default `CMAKE_BUILD_TYPE` to "Release" Signed-off-by: Steffen Jaeckel <[email protected]>
50678c1
to
ed6ad7d
Compare
So skip it. And we are installing, what, three files (binary, config, header) only, and not 1356 distributed over 11 different directories (yes, a real example *sigh*), so, yes, no need for an uninstall. |
@madebr do you maybe have something to add? I've seen that you applied some fundamental changes [0] to an older version of this branch in your local fork ... [0] madebr@db4a0f4 |
Signed-off-by: Steffen Jaeckel <[email protected]>
Signed-off-by: Steffen Jaeckel <[email protected]>
248b2f9
to
007f8a3
Compare
one for the library, one for the demo Signed-off-by: Steffen Jaeckel <[email protected]>
007f8a3
to
bca60c7
Compare
bca60c7
to
be5bef4
Compare
* split up build and test process * build and run tests twice - once from regular build folder - once from demo Signed-off-by: Steffen Jaeckel <[email protected]>
be5bef4
to
1fb5c8f
Compare
I'm going to leave this PR open until tomorrow afternoon and merge by then if there are no major issues... Maybe there are still some more things that have to be fixed or could be improved!? CC @madebr @mrpelotazo @czurnieden If someone has the passion for it, they're free to add CMake testruns on Windows, either via AppVeyor or GH actions :) but please in a fresh PR. If you're using GH actions and if that's even possible, it would maybe make sense to morph the existing CMake build matrix into something that supports both Windows and Linux. |
I am pretty sure of it but I found none (yet), seems to work as intended. Or does anybody want to port e.g.: #525 to CMake? >;-> |
* protect GCC-specific stuff * use `list(APPEND...)` * use CMake-style way to choose whether LTO should/can be done or not * only install public header, not all * add correct `install` option for DLL's on Windows * use correct folder for .pc files * check if `uname` exists & add support for FreeBSD Signed-off-by: Steffen Jaeckel <[email protected]>
Instead of prepending multiple times 'lib', change the target-properties `OUTPUT_NAME` once. This also improves cpack package names to be more distro-style. Signed-off-by: Steffen Jaeckel <[email protected]>
1fb5c8f
to
72ce1e5
Compare
@cntrump can you please update the SPM part to use the CMake way instead of the plain makefiles? |
and thanks to all contributors of this PR :) |
Adds cmake support
Fixes #468,
Related to: #70, #480, #518, #523, #524,