-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
RFC: Proposal to rework c_args and friends #4963
Comments
Putting cross arguments in an option called |
I have seen this mentioned a few times, but I'm pretty sure these |
I wasn't originally convinced by the build/host/target vs native/cross thing, but I've become convinced that thinking in build/host/target terms is correct. The fact is that generally people don't care too much about the build flags, but they do care a lot about changing the host flags, whether that's in a cross compile or not. |
#5110 reserved |
#4931 made a |
Fingers crossed, but I think #5263 should pass tests on Windows now. As I say in #5263 (comment), hopefully this means it's finally worth discussing this and related issues about native-cross vs build-host so we can reach a common understanding. edit it does. |
https://gitlab.freedesktop.org/wayland/weston/merge_requests/157/diffs Here is an example of code in the wild using prog_scanner = find_program(
dep_scanner.get_pkgconfig_variable('wayland_scanner', native: true)) i.e. always lookup on the build machine package config path. This isn't options, but the idea of |
I just shared some prototype test code in #6362 if you're interested. |
The behavior of
*_args
is currently inconsistent between native and cross builds. In native builds, it affects both the intermediate "native" tools that we want to run at build time, and the actual end-goal build targets. In a cross build, the later become "cross" targets and thus are not affected by*_args
(except those added in a cross file).There are a couple of problems with this:
What I'm suggesting is the same concept outlined in #4933: think in terms of
build
andhost
, notnative
andcross
. So instead ofc_args
etc., we could have something like this:build_<lang>_args
,build_<lang>_link_args
: used for "native" targets only (native
is explicitlytrue
).host_<lang>_args
,host_<lang>_link_args
: used for other targets (native
is eitherfalse
or unspecified).<lang>_args
set in the cross files may map tohost_<lang>_args
.native
kwarg and replace it withmachine
, accepting one of the global machine objects.The text was updated successfully, but these errors were encountered: