Allow initializing languages per-machine #14368
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It's quite common to only need languages for the host machine in a cross
compile setup, or to need only a subset of languages on the build
machine that are needed for the host. While having build machine
compilers isn't a problem for most unix-like OSes, it's particularly
annoying for MSVC users on Windows, who often need to setup a mingw
toolchain that they'll never even use. It also means that Meson will go
looking for compilers (and probe them) then never use them, wasting time
at setup.
This can be achieved with the following setup, but it's non obvious:
```meson
project('foo')
add_languages('c', native : false, required : true)
```
but this isn't really what `add_languages` is for, it's really for
languages that are conditional in ways that cannot be described, like
"when building for MacOS ObjC is required".
```meson
project('foo', host_machine_languages : 'c')
```
is much more obvious, it's adding 'c', as a required language, for the
host machine.
Since there are advantages, we should document that people do this.
bruchar1
reviewed
Mar 14, 2025
|
I don't want this to either become bikeshedding or balloon into a full design discussion, but what about making the second argument a dictionary (keyed by |
This is on my list of things todo, but that last never seems to get shorter. |
So does it make sense to use host/build already, as the keys in a languages dictionary? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When cross compiling, it's often not useful or interesting to have the same toolchain for the host and build machine. Often, a project only needs a host toolchain, and needs no build toolchain at all. In some situations (like MSVC) having to set up a build machine toolchain is painful and annoying when not needed. Alternatively, sometimes a specific language is only needed for the build machine and isn't useful for the host machine.
Currently, the only way to handle this is the non-obvious solution of not setting languages at all in the
project()call, and then adding them withadd_languages(), like so:This isn't obvious, and since many developers don't cross compile often, they don't think about cross compiling, so they don't do that, they just set the languages and everything works exactly as they expect.
Having an explicit, project call oriented way to set up the languages, makes it easier for a developer to do the right thing the first time, since they are asked to consider whether they need a toolchain for both the host and and build machines, or just for one or the other. The above could be written as:
This is abundantly clear when reading the
meson.buildfile what is necessary, and the developer had to consider what was needed. It would also open a path to using a linter to identify unused languages, or languages unused on a given machine, with a path to easily fixing that.