-
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
machine files, replacing the cross file #3972
Comments
To elaborate on @nirbheek's case:
|
@jpakkane and I discussed at GUADEC that we should probably have |
It is a good point that "build file" is already taken. I'd say just do clarity over brevity (people have shell history after all) and do:
I don't like [More broadly, see what I wrote in #3969 (comment) about the 3 machines always being defined. The idea is native compilation is just the case where |
Let me just add that https://github.com/mesonbuild/meson/pull/3921/files is a great example of on one hand the |
Bump. What do you all think of this design? I'd like to finalize something and implement it. |
The nat I'm not really a fan of splitting the cross file in two. For one the target file would not really have any executables because they are all native. There is also the case that the cross compilation setup is defined by the combination of host + target. Having them in one file is nice because then every piece of information about the cross setup is in one file. |
What do you mean by that? |
Unless one is building a compiler, there really is no target platform. Internally we have it for simplicity, and it defaults to be the host platform, but really nothing should inspect it at all; it should be dead code. In the cases that they are both present they very independently. And in fact, you probably want multiple target platforms. GCC's multilib effectively is that, but not expressed as such due to Autotools. In short the target platform isn't really a nice concept: you either want 0 or many, and I rather kind of cordon it off. |
In fact it's possible to have |
Brain fart, sorry.
Or Binutils. But yes, it is fairly rare.
Yes, but you don't do that in a single build dir but instead have one per "host machine". If the outputs are capable of producing files that target multiple platforms, then that's totally fine. Maybe just have the system or one of the other entries be "multi" or something. Or ignore |
But they aren't. Or rather shouldn't be. The trick to do multilib with minimal burden on the user is that each compiler-specific library should be written just like a normal library. Then when one goes to import the subproject they should be able to do something like:
Then Meson duplicates the project, substituting the library's host with every target we have. Yes, multi-target, one host, is more useful than multi-host since there's more to reuse (the compiler itself vs maybe a few odds-and -ends config files), but fundamentally it's the same duplicate-and-substitute approach for each, so multi-host can be done with virtually no extra implementation cost. |
When you say multilib do you mean:
|
"multilib" is GCC jargon. See https://gcc.gnu.org/install/configure.html's description of More generally (to me) it's an admission that building a compiler with multiple backends is only part of the battle. There's still the runtime libraries needed to build programs relying on the full breadth C/C++ standards. Even in LLVM land, they abuse CMake in all sorts of ways so |
Does that mean that if you need to support multiple targets then you'd need to compile, say, libatomic multiple times to get the final result? |
Yes. And even for regular projects, something like simultaneous |
Note that this is required for implementing the old feature request we had for being able to build the same executable twice: once for native (for running now) and once cross (for installing). Currently there is no way to do this cleanly. |
How does the final result get collated? Are there |
A final conceptual argument, not only is the width limit of a single host/target platform arbitrary, the depth limit of just build, host, and target is also arbitrary. Imagine we used https://github.com/mozilla/sccache or similar to distribute a single Ninja build over a heterogeneous build farm. Imagine also we added a
which would build
This may sound far-fetched, but this sort of thing is exactly what we do on the project-level rather than ninja-rule level with my distro's package set https://github.com/nixos/nixpkgs/. If you take every machine as a node, and |
@jpakkane they are not combined into "fat libs" but go in different subdirectories of |
So is the total flow like this:
And if yes, does step 2 use the compiler built in step 1 or the compiler that was used to build it (the "system" compiler)? |
The newly-built GCC is used to built the runtime libs where possible, in case they depend on new compiler features. But when the newly built GCC has |
@dcbaker I don't know if you ever saw this. Between our PRs this is all but implemented. The "build file" is exactly your "native file" (due to the way defaulting works), but I still like splitting the "cross file" into host and target files. |
Now that:
... would the following make sense?
These sections could be in the same |
The cross file must not define anything about the build machine! |
@marc-h38 we already have the native file. Now it just remains to make them take all the same sections, by adding some to the native file, and probably deprecating |
Thanks @Ericson2314
As of its last, August 2018 edit, the description suggests three new
Are you still recommending some new options today? If yes which ones? Either way would you mind updating the description and/or closing this issue with some summary why? I'm lost sorry. AFAIK we have only two now: |
I just opened #6322. If we can do that, I'll just close this issue. |
Currently, the cross file specifies:
Missing would be
build_machine
explicitly---don't merge #3689But instead of putting all this in one cross file, what if we separate the files per machine.
Each file would contain:
[binaries]
binaries targeting that machine (running on the build machine)[machine
] information about that machine[properties]
same as todayCLI would be:
That is either today's cross file is passed, or any combination of the 3 machine files is passed.
The rules for missing machine files are straightforward:
That means target default's to host, host defaults to build, and build is inferred if it's not specified. This is consistent with Autoconf's reformed behavior: https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Specifying-Target-Triplets.html. (See the link at the bottom of that page for some very odd history.)
The host machine C compiler
[binaries]
entry would cover most uses ofCC
today (autoconfCC
), and the build machine C compiler[binaries]
entry would cover the rest (autoconfCC_FOR_BUILD
).The first benefit of this is that machine configurations, which are independent, now are also specified independently. For NixOS/Nixpkgs, we already specify machines independently and with the same schema, so this would greatly simplify things, allowing us to have one Nix machine -> meson machine file implementation and use it always. Non-distro users would also benefit if they mix and match machine definitions in that they'll never need to copy the part of the cross file that doesn't change (maybe they were doing different hosts with the same target, or different targets with the same host).
The second benefit is cross compilation becomes implicit. Only if the host and build are different is cross compilation used. For example, one could pass
--host-file m.txt
on many different types of machines, and most of them would cross compile, but one of them would native compile. This allows the user to think in higher level terms of "where I want to run what I built" rather than "how I want to build this". It also supports @nirbheek's case of choosing between multiple build machines (stemming from different ABIs / processes modes supported by the same device doing the building).The third benefit it is most directly lends itself to the deduplication and simplification I propose in #3689 (comment).
This would subsume #3282, replace #3689, and complement #3969 (as that last one is strictly about environment variables, and this is strictly about files).
The text was updated successfully, but these errors were encountered: