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

Subprojects can only be built for the host machine #11121

Open
dcbaker opened this issue Nov 30, 2022 Discussed in #11120 · 8 comments
Open

Subprojects can only be built for the host machine #11121

dcbaker opened this issue Nov 30, 2022 Discussed in #11120 · 8 comments

Comments

@dcbaker
Copy link
Member

dcbaker commented Nov 30, 2022

Discussed in #11120

Originally posted by LunarLambda November 30, 2022
Project A can be cross-compiled (it's a library for command-line parsing), so does not specify native: true.

Project B must be cross-compiled (single-platform embedded project), but wants to use Project A as a subproject dependency for native: true executables.

Is there any way for Project B to tell meson it should build Project A using the native compiler?

Or would Project A need to expose a custom build option (i.e. -Dnative=true), or would it need to expose two dependencies (one cross, one native)

Something like subproject(..., native: true) would be nice, however I can see this clashing with the rule of "every subproject is executed only once", as well as fallback subprojects used with wraps.

@tristan957
Copy link
Contributor

tristan957 commented Nov 30, 2022

It would be nice to maybe use this time to come up with something much easier to understand than native: true | false (deprecation). For instance, subproject(..., native: true) would look a whole lot better as subproject(..., machines: [host_machine, build_machine]).

Every time I deal with native: true | false I have to go consult the docs.

But maybe now is not the time since I know @dcbaker has had some qualms about the way machines are currently done given what systemd has to deal with.

@eli-schwartz
Copy link
Member

It is definitely not going to yield an array of subprojects.

@tristan957
Copy link
Contributor

Good point.

Maybe subproject(..., machine: build_machine)

@dcbaker
Copy link
Member Author

dcbaker commented Nov 30, 2022

I had thought about having machines : ['build', 'host'] as an option, but in that case I thought the better solution is to return a special type that can act as either a host or a build as appropriate, kinda like both_libraries, as that would make it 100% backwards compatible

@dcbaker
Copy link
Member Author

dcbaker commented Nov 30, 2022

or possibly machine: Literal['host', 'build', 'both'] = 'host'

@tristan957
Copy link
Contributor

Are you using 'build' and 'host' so someone doesn't supply target_machine?

@dcbaker
Copy link
Member Author

dcbaker commented Nov 30, 2022

among other things, yes. but also 'both' is more ergonomic than [host_machine, build_machine]

@tristan957
Copy link
Contributor

tristan957 commented Nov 30, 2022

Your proposal seems reasonable.

jollaitbot pushed a commit to sailfishos-mirror/shared-mime-info that referenced this issue Feb 10, 2024
It is not currently possible to build a meson subproject for the build
system. Since xdgmime is only used for the tests we can move this logic
into the build-tests conditional and disables building the tests when
cross-compiling. This workaround is not ideal but it's better than not
being able to cross-compile at all.

See mesonbuild/meson#11121
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants