Meson build system support

[antoniovazquezblanco]

While playing with the build system, I found that Meson may be simpler than CMake...

I've decided to open a PR to evaluate wether this is positive or negative for the project.

Thanks

[github-actions]

Documentation coverage report

Element	Value
Defines	0.3% (1/351)
Enum Values	0.0% (0/38)
Enums	0.0% (0/12)
Files	0.0% (0/91)
Functions	0.0% (0/703)
Pages	100.0% (3/3)
Structs	2.1% (1/48)
Typedefs	0.0% (0/41)
Variables	2.5% (12/489)
Total	1.0% (17/1776)

[antoniovazquezblanco]

FFTW/fftw3#180 is making me having to patch meson CI to work in OSX. It would be nice to see it fixed...

[antoniovazquezblanco]

This is done to the exception of packaging... I would love to have that but it may not be that easy...

[antoniovazquezblanco]

Now without removing CMake support. Documentation is failing due to github trying to use old ci files. Should be fixed with the merge of the PR.

[BatchDrake]

Just tried it and, while I do like it (I have just seen a bunch of unused variable warnings I am going to fix ASAP) I see that the libraries are installed with the wrong version suffix. This is how I did it:

% meson setup build
% cd build
% meson compile
% sudo meson install
ninja: Entering directory `/home/waldo/Documents/Desarrollo/sigutils/build'
ninja: no work to do.
Installing src/libsigutils.so.0.1 to /usr/local/lib/x86_64-linux-gnu
[...]
Installing symlink pointing to libsigutils.so.0.1 to /usr/local/lib/x86_64-linux-gnu/libsigutils.so.0
Installing symlink pointing to libsigutils.so.0 to /usr/local/lib/x86_64-linux-gnu/libsigutils.so

[BatchDrake]

This is a minor though, I believe it will suffice to change this line in the top-level meson.build:

project('sigutils', ['c', 'cpp'], version: '0.1', default_options: ['cpp_std=c++17'])

[BatchDrake]

Two issues:

• Libraries are installed in /usr/local/lib/x86_64-linux-gnu/. This is not in my $LD_LIBRARY_PATH. With CMake, they were installed in /usr/local/lib.
• This makes SigDigger crash when I press the capture button, and it seems some obscure, undebuggable issue in fftw during plan creation:

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `SigDigger'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fe45d18c36e in ?? () from /lib/x86_64-linux-gnu/libfftw3f.so.3
[Current thread is 1 (Thread 0x7fe409e3e6c0 (LWP 4024073))]
(gdb) bt
#0  0x00007fe45d18c36e in  () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#1  0x00007fe45d031b57 in  () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#2  0x00007fe45d02b92e in fftwf_measure_execution_time () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#3  0x00007fe45d027b1e in  () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#4  0x00007fe45d027d8f in  () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#5  0x00007fe45d027f4c in  () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#6  0x00007fe45d02862f in fftwf_mkplan_d () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#7  0x00007fe45d02f7d3 in  () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#8  0x00007fe45d027cce in  () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#9  0x00007fe45d027f4c in  () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#10 0x00007fe45d1169d4 in fftwf_mkapiplan () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#11 0x00007fe45d11dc58 in fftwf_plan_many_dft () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#12 0x00007fe45d11d0a7 in fftwf_plan_dft () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#13 0x00007fe45d11ce66 in fftwf_plan_dft_1d () at /lib/x86_64-linux-gnu/libfftw3f.so.3
#14 0x00007fe45d28139a in su_lib_plan_dft_1d (n=4096, in=0x7fe4505bc000, out=0x0, sign=-1, flags=0) at ../src/sigutils/lib.c:156
#15 0x00007fe45d289281 in su_specttuner_plan_new (in=0x7fe4505bc000, out=0x0, size=4096, offset=2048) at ../src/sigutils/specttuner.c:528
#16 0x00007fe45d288fa1 in su_specttuner_make_plan (self=0x55f223f713e0, in=0x7fe4505bc000) at ../src/sigutils/specttuner.c:470
#17 0x00007fe45d491942 in suscan_local_analyzer_read_circ (self=0x55f2237eada0, got=0x7fe409e3d698) at /home/waldo/Documents/Desarrollo/suscan/analyzer/workers/channel.c:647
#18 0x00007fe45d49239c in suscan_local_analyzer_circbuf_channelizer_wk_cb (mq_out=0x55f2237eada8, wk_private=0x55f2237eada0, cb_private=0x55f22240b230) at /home/waldo/Documents/Desarrollo/suscan/analyzer/workers/channel.c:845
#19 0x00007fe45d4cc62e in suscan_worker_thread (data=0x55f223f70e70) at /home/waldo/Documents/Desarrollo/suscan/analyzer/worker.c:101
#20 0x00007fe45b8ecfd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#21 0x00007fe45b96d66c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
(gdb) 

Can you reproduce?

[BatchDrake]

I have just given a look to both libsigutils generated by Meson and CMake, and it seems the only difference between both is the order in which certain libraries are loaded:

With CMake:

(metalloid) % ldd /usr/local/lib/libsigutils.so.1                                                    
        linux-vdso.so.1 (0x00007ffee6e33000)
        libfftw3f.so.3 => /lib/x86_64-linux-gnu/libfftw3f.so.3 (0x00007f1016e00000)
        libfftw3f_threads.so.3 => /lib/x86_64-linux-gnu/libfftw3f_threads.so.3 (0x00007f1017172000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1017093000)
        libvolk.so.2.5 => /lib/x86_64-linux-gnu/libvolk.so.2.5 (0x00007f1016a00000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f101681f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f10171ef000)
        liborc-0.4.so.0 => /lib/x86_64-linux-gnu/liborc-0.4.so.0 (0x00007f1016d7c000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f101708c000)

With Meson:

(metalloid) % ldd  /home/waldo/Documents/Desarrollo/sigutils/builddir/tests/./../src/libsigutils.so.0
        linux-vdso.so.1 (0x00007ffd086e9000)
        libfftw3f.so.3 => /lib/x86_64-linux-gnu/libfftw3f.so.3 (0x00007ff934000000)
        libfftw3f_threads.so.3 => /lib/x86_64-linux-gnu/libfftw3f_threads.so.3 (0x00007ff93437d000)
        libvolk.so.2.5 => /lib/x86_64-linux-gnu/libvolk.so.2.5 (0x00007ff933c00000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff93429e000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff933a1f000)
        liborc-0.4.so.0 => /lib/x86_64-linux-gnu/liborc-0.4.so.0 (0x00007ff933f7c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007ff9343fa000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff934297000)

[BatchDrake]

It does not seem to be related by the generated library either. I replaced one with the other and now it works. I believe the culprit is the .pc files generated by Meson:

CMake:

(metalloid) % cat build/src/sigutils.pc
# sigutils library pkg-config file
# Automatically generated by CMAKE

prefix=/usr/local
exec_prefix="${prefix}"
libdir="${prefix}/lib"
includedir="${prefix}/include"

Name: sigutils
Description: Digital signal processing utility library
URL: http://github.org/BatchDrake/sigutils
Version: 0.3.0 
Cflags: -I${includedir} -D_SU_SINGLE_PRECISION -DHAVE_VOLK
Libs: -L${libdir} -lsigutils -lsndfile -lfftw3f -lfftw3f_threads -lm -lvolk

Meson:

(metalloid) % cat builddir/meson-private/sigutils.pc

prefix=/usr/local
includedir=${prefix}/include
libdir=${prefix}/lib/x86_64-linux-gnu

Name: sigutils
Description: sigutils: sigutils
Version: 0.3.0
Libs: -L${libdir} -lsigutils
Cflags: -I${includedir} -DHAVE_VOLK -D_SU_SINGLE_PRECISION