Start adding native : 'both'
#12022
Start adding native : 'both'
#12022
Conversation
|
This is needed for cross-compiling Mesa. Could someone give it a review? |
| @@ -2,9 +2,12 @@ project('add language', 'c') | |||
|
|
|||
| test('C', executable('cprog', 'prog.c')) | |||
|
|
|||
| assert(add_languages('cpp', native: false), 'Add_languages returned false on success') | |||
| assert(add_languages('cpp', native: 'both'), 'Add_languages returned false on success') | |||
There was a problem hiding this comment.
Shouldn't that fail when not cross compiling?
There was a problem hiding this comment.
Hm, better to accept it indeed, just like we allow native: true and native: false to mean the same thing when not cross compiling. But maybe that should be said in doc explicitly.
There was a problem hiding this comment.
I've updated the docs to be explicit that in a host == build configuration, that all values to native have the same meaning.
| native = kwargs['native'] | ||
| if native is InterpreterMachineChoice.BOTH: | ||
| self._add_global_arguments(node, self.build.global_args[MachineChoice.HOST], args[0], kwargs) | ||
| self._add_global_arguments(node, self.build.global_args[MachineChoice.BUILD], args[0], kwargs) |
There was a problem hiding this comment.
Wondering if this would duplicate all args when doing a native build, because in that case HOST and BUILD machines are the same, right?
There was a problem hiding this comment.
I thought that at first too, and added a bunch of code, only to discover that no, it doesn't. I've added a test in the lastest version to ensure that.
dcbaker
force-pushed
the
wip/2023-07/native-both
branch
from
bb501ad to
76623b2
Compare
|
I still haven't added the necessary skip test calls to get the cross only environments passing, just rebased and tried to address comments. |
dcbaker
force-pushed
the
wip/2023-07/native-both
branch
from
76623b2 to
46e2c61
Compare
Forgive me for breaking into the discussion. Would that solve #10947? |
|
@Nomura-RH not inherently, but it's something I want to solve to make dependency both work, so It's on my list of things to do. |
dcbaker
force-pushed
the
wip/2023-07/native-both
branch
3 times, most recently
from
676851f to
2a8fa76
Compare
dcbaker
force-pushed
the
wip/2023-07/native-both
branch
from
2a8fa76 to
ee83941
Compare
|
This PR looks good to me |
This allows at the interpreter level to specify that we want both the
host and build machine (if we're cross compiling). We don't want to pass
this out of the interpreter level, however, since this is an abstraction
in the interpreter to simplify cases like:
```meson
add_languages('c', native : true)
add_languages('c', native : false)
```
to
```
add_languages('c', native : 'both')
```
(plus other things later)
This keeps the behavior of not setting the `native` keyword argument, but with an explicit way to to ask for both. As an added advantage we can simplify things, and get rid of a warning abut not setting `native`.
This allows for arguments that are needed for both machines to be passed to both at the same time. This can be helpful if when cross compiling, when something like a `-D` option needs to be the same for the host and the build targets.
dcbaker
force-pushed
the
wip/2023-07/native-both
branch
from
ee83941 to
66e5c4b
Compare
|
Any reason for this being stalled? We're interested in using libclc in Mesa to precompile some shaders for Panfrost, and it seems this is the only viable approach to not have to duplicate all involved dependencies and build-rules etc... |
|
@kusma, dcbaker has been rather busy, so this PR has been stalled. |
This is useful for some people. This doesn't allow building thunks due to the cmake limitation about tools binaries also getting cross compiled, we need to switch to meson if we want that, since they recently started fixing this mesonbuild/meson#12022 But that's an okay limitation for now.
This is based on top of #11981
This adds a new value to the
nativefield of theadd_languages()andadd_*_args()functions. This allows targeting both the build and host machine explicitly, instead of implicitly in the case ofadd_languages(), or with two calls toadd_*_args().This is a first set of patches, I'm working toward extending both
dependency()and thebuild_target()family to accept this as well, to simplify handling cases of needing both a host and a build dependency/target