build: add support for meson #3128
Conversation
|
@frankmorgner @Jakuje The libraries Questions:
|
|
The OpenSC API is considered as an internal API (even though we still try to version it). The libssm-local.so is API for openSC to handle Secure Messaging. I think, in theory, it can be used as plug-able API for third party implementation of the SM talking to specific cards in "more secure" manner (read closed source). I think the reason to version them separately is the SM API is much more stable (there are only few functions) so I think the idea was not to break it with the changes in opensc API, but I do not know if there are any users of this now. Regarding the OpenSC API, as I mentioned previously, we consider it internal, we do not ship pkgconfig files and do not advise anyone using it outside of opensc tools. Generally, any application that wants to use OpenSC should go through the PKCS#11 API, which is standardized. |
|
@H5117 see https://www.sourceware.org/autobook/autobook/autobook_61.html for more information about the reasoning behind this library version. |
There was a problem hiding this comment.
Thank you, this will really facilate the on-boarding process of new developers.
The following features are missing (did I miss any?), so that we would have to support autotools a little longer:
- unittests, p11tests (code coverage, valgrind, fuzzing even though a switch exists, cmocka)
- clang-tidy
- disable warning
-Wno-unknown-warning-optionif needed
One benefit over the autotools is that dependencies are listed explicitly for each executable.
Would it be possible to create some github workflow for visual studio an xcode on windows/mac and plain meson on linux?
The test scripts in |
The paths are defined as part of Line 11 in 1fb5655 So just creating an environment variable |
Meson automatically generates a target to check all sources in the project with clang-tidy (link). Is it OK for you or you need to check only specific files? EDIT: implemented. |
Could you explain why you use this option only for some tools and not for the whole project? |
|
By the way, should we install legacy symlinks for onepin-opensc-pkcs11.so in new build system? If someone decide to switch building to Meson, he can also switch to opensc-pkcs11.so. |
For some tools we are using code generation for CLI parsing. The generated files are causing this warning, so we need to disable this warning explicitly for those files. |
|
Lines 144 to 148 in 1fb5655 |
This is about PKCS#11 users rather than developers. We don't want to break existing configurations or scripts using the old location of the module. |
H5117
force-pushed
the
meson
branch
2 times, most recently
from
26f2067
to
4f9b154
Compare
Fixed. |
|
thank you. One thing we struggled setting up with the autotools is the pure static linking of the pkcs11 module. We had several tries of doing this, but did not manage to set this up correctly. |
|
I added options to control static linking. Works for me. Static linkingFor external dependencies Meson has an option |
|
Thank you for this work so far. I think it is going in the right direction. I put there some inline comments. Can you also adjust the CI configuration and scripts to use the meson instead of autotools (at least for now to see how it behaves -- then we can figure out if we can adjust it somehow to run both). |
Yes, would be the preferred linking for pkcs11 modules (for both, internal and external dependencies). This would allow an application to include multiple pkcs11 modules with different types os versions of dependencies. For the opensc tools, however, shared linking woul be preferred for both. |
I added optional compiling of static external dependencies, so this is now possible. With commands: meson setup --prefix=/usr -Dcomponents=pkcs11 -Dp11kit=disabled -Dlibopensc=static --wrap-mode=forcefallback . build-static
cd build-static
meson configure -Dlibffi:default_library=static
meson configure -Dproxy-libintl:default_library=staticI get this result: Currently OpenPACE and readline are not compiled, but can be added later. |
Co-authored-by: Frank Morgner <frankmorgner@gmail.com> Co-authored-by: Jussi Pakkanen <jpakkane@gmail.com>
Implemented. Commands: Result: |
Fixes #3110.