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
interpreter: add a new function add_project_dependencies() #10206
interpreter: add a new function add_project_dependencies() #10206
Conversation
This would also spare @rgommers the need to check if Seems reasonable enough, anyway. |
add_project_arguments and suchlike cannot be used after build targets have been defined, IIRC. |
I think you could use |
Codecov Report
@@ Coverage Diff @@
## master #10206 +/- ##
===========================================
- Coverage 68.48% 50.30% -18.19%
===========================================
Files 406 203 -203
Lines 87400 43590 -43810
Branches 19422 9664 -9758
===========================================
- Hits 59854 21926 -37928
+ Misses 23044 19688 -3356
+ Partials 4502 1976 -2526
Continue to review full report at Codecov.
|
No, I mean this: meson/mesonbuild/interpreter/interpreter.py Lines 2670 to 2682 in 80192aa
It's forbidden to add global/project compile/link arguments if that would override the immutability of a previously declared build target. This isn't about the one you just created. Any build target at all. |
I understand, but I don't understand why it's relevant. I'm sure it is, but I am missing the link. |
6abd06a
to
3958cd4
Compare
3958cd4
to
e905322
Compare
EDIT: I now see it shares implementation with add_project_arguments. This official GitHub app is trash and makes diffs practically unreadable. Back to the website it is. |
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.
I've only looked at the implementation, not at whether this is a good idea. I'm leaving that up to @jpakkane
For context, that code can be found here and looks like: # We need -lm for all C code (assuming it uses math functions, which is safe to
# assume for SciPy). For C++ it isn't needed, because libstdc++/libc++ is
# guaranteed to depend on it. For Fortran code, Meson already adds `-lm`.
m_dep = cc.find_library('m', required : false)
if m_dep.found()
add_project_link_arguments('-lm', language : 'c')
endif That is't too bad in the end, but figuring out the details and how every language treats |
e905322
to
33bc6b0
Compare
33bc6b0
to
044f39a
Compare
Would be pretty interesting to see an |
Could be nice, but that could already be done easily with this PR:
Implementation looks good to me and I like the idea as well. LGTM. |
Using |
Yep good point. My motivation for making that comment was essentially that we now have global options for all the important kwargs in build_target(): add_project_link_args(), add_project_args(), add_project_dependencies(). So adding add_project_include_directories() would finish it out in my opinion. |
044f39a
to
983d99a
Compare
983d99a
to
97a4353
Compare
@dcbaker, does it look good now? |
Also ping @jpakkane. |
There needs to be a test that you can't call this function after any build targets have been defined. project(...)
executable(...)
add_project_dependencies(...) # <- Must error out. This is in line with how other such functions work. |
This does dispatch to |
On top of that, it is also enforced by the fact that the dependency cannot be a "built" one. See also the new |
That doesn't really assert anything as the restriction jpakkane mentioned is about forbidding any dependencies at all, not built ones specifically. |
97a4353
to
ef6ff51
Compare
Ping. |
@bonzini it conflicts now, but looks good to me. |
Both dependencies.ExternalLibrary and dependencies.InternalDependency are subclasses of dependencies.Dependency, no need to list them separately. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Extract to a separate function the code that resolves dependencies for compiler methods. We will reuse it for add_project_dependencies(). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
ef6ff51
to
bad073a
Compare
This function can be used to add fundamental dependencies such as glib to all build products in one fell swoop. This can be useful whenever, due to a project's coding conventions, it is not really possible to compile any source file without including the dependency. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Test that add_project_dependencies() can only be used before build targets have been declared. Also test that one cannot use override_dependency on a superproject to inject a superproject's build products into the subproject. This would violate the rule that build products cannot be used with add_project_dependencies() (similar to e.g. compiler.has_function), so check that meson detects the situation correctly.
bad073a
to
8d437e2
Compare
LGTM when CI is green, thanks! |
This function can be used to add fundamental dependencies such as
libm
,dependency('threads')
or glib to all build products in one fell swoop. This can be useful whenever, due to a project's coding conventions, it is not really possible to compile any source file without including the dependency.This function also makes it possible to add an
include_directories()
object to the project, removing the need to list both source and global directories. An example from QEMU is this:which might become: