TimingBlock: Initial sample and a bit of documentation

[wirew0rm]

Update readme with with information about building timing dependencies and switch from meson to cmake.

Add a simple UI example on how to get timing messages which is not yet a gnuradio block.

Screen capture of the UI with the picoscope application above to show the generated trigger pulses.

[frankosterfeld]

Cool, we might want to port the timing_receiver_simulated block from dev-4.0 branch and make sure it has a unified (settings) API with the real thing.

[alexxcons]

and switch from meson to cmake

Meh, that's a pity. Why did you have to do so ?

[wirew0rm]

and switch from meson to cmake

Meh, that's a pity. Why did you have to do so ?

That was mostly to keep the Readme in sync with the rest of the repository. This in turn depends on the meson adoption in graph-prototype/gnuradio4.0. We were experimenting there with having both cmake and meson in parallel to evaluate them, but the meson support is currently not up to date and disabled. Historically GNURadio uses some less standard cmake features for its OOT modules and it's not yet clear how this will translate to gr4.0 and eventually meson.

At the moment it might be a bit of a "the devil you know" kind of situation. It's also probably good to not judge cmake on cmake build systems written 10y ago, so we'll see where we end up.

[alexxcons]

and switch from meson to cmake

Meh, that's a pity. Why did you have to do so ?

That was mostly to keep the Readme in sync with the rest of the repository. This in turn depends on the meson adoption in graph-prototype/gnuradio4.0. We were experimenting there with having both cmake and meson in parallel to evaluate them, but the meson support is currently not up to date and disabled. Historically GNURadio uses some less standard cmake features for its OOT modules and it's not yet clear how this will translate to gr4.0 and eventually meson.

At the moment it might be a bit of a "the devil you know" kind of situation. It's also probably good to not judge cmake on cmake build systems written 10y ago, so we'll see where we end up.

Ok, thank you for the details!

[sonarcloud[bot]]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
20 Code Smells

3.4% Coverage
1.2% Duplication

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[wirew0rm]

Look generally good. There some holes w.r.t. documentation and notably the plot.hpp needs some refactoring to be in line with the C++ core guidelines, GR 4.0 (naming guidelines), and other standards.

We should better fix that immediately rather than dragging this to the unknown future. Also there are some quite unsafe raw-pointer arithmetics that I am a bit scared of.

Thanks for the review and the suggestions, I tried to apply them and also reduce the SonarCloud issues to a minimum.

The clang build failures are due to a packaging error in clang's ubuntu repositories, the issue is known and will be fixed, there is unfortunately not much we can do here other than wait: https://github.com/llvm/llvm-project/issues/74766