x.py install does nothing when target is set but host is not

[tmandry]

With a valid install prefix under install.prefix in config.toml, I see this:

./x.py install
Updating only changed submodules
Submodules updated in 0.04 seconds
    Finished dev [unoptimized + debuginfo] target(s) in 0.17s
Build completed successfully in 0:00:00

But nothing is installed. This is a recent regression. At first I thought it had to do with the default stages changing, but passing --stage doesn't seem to have an effect.

[tmandry]

It looks like this regressed in #76415, cc @Mark-Simulacrum

[jyn514]

The default stage for install and dist is still stage 2.

[Mark-Simulacrum]

@tmandry Can you tell me what your config.toml contains? With an empty one I cannot seem to reproduce; I see x.py install go off to build a compiler at least (I did not wait for it to finish).

[tmandry]

Here's a config.toml:

[build]
target = ["x86_64-unknown-linux-gnu"] # happens to be the platform I'm building on
docs = false
extended = true
tools = ["cargo", "clippy", "src"]

[install]
prefix = "/absolute/path/to/some/existing/but/empty/dir"

Oddly if I remove target, docs, or tools it starts building std. Also oddly, extended seems to have no impact even though I think it should.

[Mark-Simulacrum]

Okay, I think I know what the problem is. That target config in build means that we're not building any host-only steps, of which I think everything except docs (edit: and analysis, which I think is save-analysis data, certainly not needed, but explains the tools thing) are currently in x.py install. Why everything is host-only, I'm not sure; I think at least std should not be.

What do you expect to install in that scenario? A full compiler toolchain?

[tmandry]

Yes (edit: and libstd/libtest), or at least that's what happened in the past.

For what it's worth we normally specify more targets than just the one, but this was enough to show the issue. (It does the same thing when there are multiple targets)

[Mark-Simulacrum]

Hm, okay. So the past behavior was almost certainly either a bug or at least unintentional. I think std should be installed for every target, but everything else I wouldn't expect to get installed without a configuring the platform as a host; if you want full toolchains you likely want target and host to be configured identically.

[tmandry]

I only need one host, multiple targets. It's surprising to me that specifying a target appears to override the default host?

[tmandry]

Maybe I'm confused about the role of host and target. Let's say I want the compiler to run only on linux x64, and be able to target linux-x64, fuchsia-x64, fuchsia-arm64. What should my configuration be?

[Mark-Simulacrum]

host = x64 linux
target = x64 linux, fuchsia x64, fuchsia arm64

The behavior of implicitly setting host to empty if only target is specified is not necessarily desirable, it's just a historical artifact (used to be only on command line, the PR you cited earlier made it uniform between files and CLI). I think removing that behavior and requiring an explicitly empty host list probably makes sense, if you truly only want target artifacts.

[tmandry]

Okay, I'm working on a change to do that. Thanks for the explanation!