Skip to content
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

dependencies: add custom atomic dependency #11445

Merged
merged 1 commit into from
Dec 30, 2024

Conversation

Dudemanguy
Copy link
Contributor

Almost exactly the same as how the dl dependency works. On certain systems (like BSDs that use clang), stdatomic is provided by compiler-rt and doesn't need a separate library explictly linked. On a typical GNU/LINUX system, atomic is a separate library that must be explictly found and linked against. So just add a builtin and system method for these two use cases.

@Dudemanguy Dudemanguy requested a review from jpakkane as a code owner February 23, 2023 16:17
@codecov
Copy link

codecov bot commented Feb 23, 2023

Codecov Report

Merging #11445 (231ab94) into master (eb472a1) will increase coverage by 3.44%.
The diff coverage is n/a.

❗ Current head 231ab94 differs from pull request most recent head 4a56692. Consider uploading reports for the commit 4a56692 to get more accurate results

@@            Coverage Diff             @@
##           master   #11445      +/-   ##
==========================================
+ Coverage   65.25%   68.70%   +3.44%     
==========================================
  Files         420      209     -211     
  Lines       91410    45429   -45981     
  Branches    20305     9402   -10903     
==========================================
- Hits        59648    31211   -28437     
+ Misses      27115    11817   -15298     
+ Partials     4647     2401    -2246     

see 273 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@jscott0
Copy link
Contributor

jscott0 commented Mar 26, 2023

I'm not qualified to review this, but it's been a long time since atomics were merged into the C standard, and since POSIX hasn't yet addressed the issue, I very much welcome Meson's support for an atomic dependency

@thesamesam
Copy link
Collaborator

thesamesam commented Mar 29, 2023

The discussion in #10621 is relevant. I need to look at this more later though, we've run into a series of issues on odd platforms with atomic tests.

@Dudemanguy
Copy link
Contributor Author

The intention is indeed to first check if atomics is already provided and if not try to link the atomic library if possible. I confess that I do not know if atomics are more complicated than that.

@Dudemanguy
Copy link
Contributor Author

I bumped it to 1.2.0 now.

@Dudemanguy
Copy link
Contributor Author

Updated to 1.3.0 now.

@Dudemanguy Dudemanguy force-pushed the stdatomic-dep branch 2 times, most recently from 2007324 to fc07c2b Compare June 23, 2024 14:56
Comment on lines 584 to 591
'atomic',
[DependencyMethods.BUILTIN, DependencyMethods.SYSTEM],
builtin_class=AtomicBuiltinDependency,
system_class=AtomicSystemDependency,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has come up in Gentoo before, which also had a test to add -latomic to LDFLAGS after running some test code to see if it's necessary for a successful link.

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ec90f4c3a4e0ef9841dede7b18df90e2aceafd45

We (I, actually) disabled that and replaced it with some code that says "is -latomic a valid library? Good, then use it unconditionally with -Wl,--push-state,--as-needed,-latomic,--pop-state". The reason was that the test often misfired because the test code could be satisfied via builtins, but more advanced use cases in the software being built required explicit -latomic.

So I wonder if maybe we really need to first check DependencyMethods.SYSTEM, on the same assumption: if -latomic is a valid external library, adding it to be cautious is assumed to never be harmful. It makes the compiler command line potentially longer and the linker has to add another library to search through for available symbols, but that's not a huge problem given the alternative.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, that sounds reasonable to me. I swapped the order so the system method is checked first.


Provides access to the atomic operations library. This first attempts
to look for a valid atomic external library before trying to fallback
to what is provided by the libc.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
to what is provided by the libc.
to what is provided by the C runtime libraries.

but let's fix that on merge to avoid delaying this more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, since we forgot to re-review this a while back we do need to bump the new-since version number yet again... :)

Other than that though I do think this looks quite reasonable.

Copy link
Member

@eli-schwartz eli-schwartz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks pretty good. Sorry for not reviewing it earlier. Minor formatting nits below but otherwise LGTM.

Needs the version number to be bumped up yet again to 1.7.0, I'm afraid. :(

@@ -50,6 +50,27 @@ def netcdf_factory(env: 'Environment',
packages['netcdf'] = netcdf_factory


class AtomicBuiltinDependency(BuiltinDependency):
def __init__(self, name: str, env: 'Environment', kwargs: T.Dict[str, T.Any]):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: the codebase now depends on python 3.7 and as such, uses from __future__ import annotations everywhere. That means we don't need to quote annotations to defer them anymore. We should use the new style, i.e. avoid the quotes, when adding brand-new code



class AtomicSystemDependency(SystemDependency):
def __init__(self, name: str, env: 'Environment', kwargs: T.Dict[str, T.Any]):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(and same here)

Almost exactly the same as how the dl dependency works. On certain
systems (like BSDs that use clang), stdatomic is provided by compiler-rt
and doesn't need a separate library explictly linked. On a typical
GNU/LINUX system, atomic is a separate library that must be explictly
found and linked against. So just add a builtin and system method for
these two use cases.
@Dudemanguy
Copy link
Contributor Author

Totally forgot about this PR as well. Rebased and updated.

@eli-schwartz
Copy link
Member

eli-schwartz commented Dec 27, 2024

Thanks for the rebase, will review on Sunday as I'm out of time today

@eli-schwartz eli-schwartz merged commit f070670 into mesonbuild:master Dec 30, 2024
34 checks passed
@Dudemanguy Dudemanguy deleted the stdatomic-dep branch December 30, 2024 03:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants