add meson build system

[eszlari]

No description provided.

[x42]

While I do like meson, I'm not yet prepared to maintain two build systems nor move away from autotools.

The main issues I'm facing with meson is cross compilation and symbol visibility. It's also not easy to use on older and embedded systems.

I'll leave this PR open, until meson matures sufficiently to supersede autotools.

[jmaibaum]

Shouldn't this be '1.3.1' or rather:

Suggested change

	version : '11.1.0',
	version : meson.project_version(),

[jmaibaum]

How about declaring our own dependency? This would allow using the library as a meson subproject:

Suggested change

	description : 'linear/longitudinal timecode library')
	description : 'linear/longitudinal timecode library')
	ltc_dep = declare_dependency(link_with : ltc_lib,
	include_directories : inc)

[tp-m]

A meson port is also available here now: https://gitlab.freedesktop.org/gstreamer/meson-ports/libltc (including CI).

Cross-compilation for embedded targets is not a problem (see CI).

I didn't think to check for an existing port, so didn't see this PR, sorry.

I have a slightly different test setup that doesn't rely on a shell for what it's worth.

The tests are failing for the MSVC build on Windows for me though, but I haven't investigated if those are issues with the test code or the library itself.

[x42]

Symbol visibility is still not done correctly. auto-tools's export-symbols-regex '^(ltc_).*

[tp-m]

You mean it's not done using a regexp? It works just fine using the .def file.

[x42]

mesonbuild/meson#65

[tp-m]

Ok, that's unlikely to change, and symbol export is better done via a dedicated LTC_API define or such anyway tbh :)

[tp-m]

(Happy to make a PR for that if you think that'd be acceptable.)

[eli-schwartz]

Using regular expressions seems primarily problematic since you'd have to generate a def file or linker script dynamically by analyzing the object files. Leaning on the linker itself for glob support is convenient here.

That being said, a similar feature for exporting all symbols is already requested at mesonbuild/meson#2132 so I would say that supporting regular expressions isn't necessarily off the table either. :)

Regardless, it appears any related feature whatsoever is probably not quite... close... to being implemented and released, so just including the symbol list directly rather than calculating it in the middle of the build using libtool regexes, is probably the straightforward solution here.