-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add meson build system #58
base: master
Are you sure you want to change the base?
Conversation
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. |
ltc_src, | ||
include_directories : inc, | ||
dependencies : m_dep, | ||
version : '11.1.0', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be '1.3.1'
or rather:
version : '11.1.0', | |
version : meson.project_version(), |
version : meson.project_version(), | ||
name : 'libltc', | ||
filebase : 'ltc', | ||
description : 'linear/longitudinal timecode library') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about declaring our own dependency? This would allow using the library as a meson subproject:
description : 'linear/longitudinal timecode library') | |
description : 'linear/longitudinal timecode library') | |
ltc_dep = declare_dependency(link_with : ltc_lib, | |
include_directories : inc) |
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. |
Symbol visibility is still not done correctly. auto-tools's |
You mean it's not done using a regexp? It works just fine using the .def file. |
Ok, that's unlikely to change, and symbol export is better done via a dedicated |
(Happy to make a PR for that if you think that'd be acceptable.) |
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. |
No description provided.