Add meson build-system support#153
Conversation
[Why] Although the Makefile works perfectly fine as it is right now. It is somewhat dated. Also it makes cross-compiling and packaging a bit tedious. Signed-off-by: Soeren Grunewald <soeren.grunewald@desy.de>
| @@ -0,0 +1,8 @@ | |||
| libexample_commoncxx = static_library('common', 'scpi-def.cpp', | |||
| include_directories : [ inc, include_directories('.') ], | |||
There was a problem hiding this comment.
Since meson 0.50 (you specified an 0.60 minimum requirement), the arguments to include_directories: [...] can be a string, and it is automatically converted as though the include_directories() function was used. The function is still useful for e.g. defining the inc variable in one directory and using it in another. :)
That being said, implicit_include_directories: true is the default and means that executables/libraries already, implicitly, have '.' as an include directory. So this is redundant.
(You still need it down below for declare_dependency. :))
|
|
||
| inc_private = include_directories( '.' ) | ||
|
|
||
| libscpi = both_libraries('scpi', |
There was a problem hiding this comment.
Instead of both_libraries, I would generally recommend using library() but setting the meson project option default_options: ['default_library=both'].
This allows end users to decide which ones they need, if they really want to. Unless there's a technical reason why the software requires that all users have both of them.
| test('fifo', | ||
| executable('fifo', 'test_fifo.c', dependencies: deps) | ||
| ) | ||
|
|
||
| test('lexer_parser', | ||
| executable('lexer_parser', 'test_lexer_parser.c', dependencies: deps) | ||
| ) | ||
|
|
||
| test('parser', | ||
| executable('parser', 'test_parser.c', dependencies: deps) | ||
| ) | ||
|
|
||
| test('scpi_utils', | ||
| executable('scpi_utils', 'test_scpi_utils.c', dependencies: deps) | ||
| ) | ||
| endif |
There was a problem hiding this comment.
You could probably do all this with a foreach loop, too.
|
|
||
| cc = meson.get_compiler('c') | ||
|
|
||
| install_data(files(['LICENSE', 'README.md'])) |
There was a problem hiding this comment.
The current Makefile doesn't install README.md anywhere... I wonder how generally useful this is?
The LICENSE file, since meson 1.1.0, can be handled via https://mesonbuild.com/Reference-manual_functions.html#project_license_files
|
@soerengrunewald Do you plan to finish this pull request? :) I want to add a library into wrapdb. If you don't plan to, I could continue for you. @j123b567 What do you think about using meson in the project? You don't mind this? |
So instead of switching the build system (which makes no sense for me personally), I would prefere a tutorial and examples, how to intergrate this code with some other build tools of users projects, like make, meson, cmake, PlatformIO, Visual Studio, LabWindows, SCons, Ninja, ... Which would be much more useful then forcing others to use just another build system that is popular today. |
|
Got it. Then I'll try adding the library to wrapdb (this is a package manager in meson). If it works, then we can add new information about the integration to the readme. |
Nope, cmake is a build system, it doesn't generate them. It configures itself and then generates Makefiles to handle parallelism, but the Makefiles execute the cmake binary. Meson and GNU autotools are similar to cmake here.
No real index other than Linux distros, but there's a standard way to ask if a library is available: pkg-config. (This PR includes the creation of a pkg-config file.) |
Just to note that CMake is really just a generator or meta-build system like meson and autotools. (It is also a scripting enging |
4 participants
Although the Makefile works perfectly fine as it is right now, it is somewhat dated. Also it makes cross-compiling and packaging a bit tedious.
So this will allow to build the library and some of the examples with meson.