Target Bundles by nagisa · Pull Request #1711 · rust-lang/rfcs

nagisa · 2016-08-09T14:24:09Z

Amanieu · 2016-08-09T15:27:36Z

text/0000-target-bundles.md

+        "target_env": "gnu",
+        "target_vendor": "unknown",
+        "target_has_atomic": ["8", "16", "32", "64"],       // any of #[cfg(target_has_atomic={"8", "16", "32", "64")] work.
+        "target_has_atomic_ptr": null,


I would prefer the previous system where you only need to specify a single value for atomic support: just the maximum atomic bit width supported by the target. It's much simpler and gives the same information.

codyps · 2016-08-09T15:34:34Z

If we're going to change the target format anyway (by moving around json keys as proposed here), I'm not sure what the downside of switching to toml would be (and at that point we'll get comments natively, and have the same config format as cargo)

codyps · 2016-08-09T15:36:38Z

text/0000-target-bundles.md

+values, though.
+
+# Alternatives
+[alternatives]: #alternatives


Seems like an alternative (in some sense) would be to have a rustc --print target-spec option that spit out more info.

Its not an alternative at all, because that option does not help creating and distributing custom targets.

It's a solution to the issue of being able to determine information about a target externally (which I saw as one of the motivations for moving all targets to json), but you're right that it doesn't have anything to do with creating & distributing custom targets.

I've got the code for rustc --print target-spec at https://github.com/cardoe/rust/tree/target-spec I'll gladly resubmit it.

nagisa · 2016-08-09T16:45:32Z

@Amanieu commented on the line 128 (about target_has_atomic):

I would prefer the previous system where you only need to specify a single value for atomic support: just the maximum atomic bit width supported by the target. It's much simpler and gives the same information.

GitHub really needs a way to mark comments as not-outdated.

Ericson2314 · 2016-08-09T18:34:40Z

Speaking of cross compiling, I think rustc should support separate build and host platforms (to use the autoconf terminology---which we may want to abandon as there's no need to ever bake in a target so 2 platforms suffices). This would certainly make build.rs easier to work with.

Also, while I'd like to do this ASAP, I don't think it should be stabilized ASAP as there is some interaction with scenarios.

Ericson2314 · 2016-08-09T18:39:49Z

Also, Now more than ever, it should be clear that that the target triple does not determine the target. So that we still by default name build directories by the target triple is prone for errors. I think there should at least be an option (if not the default) to instead normalize the config JSON, hash it, and use the hash instead.

codyps · 2016-08-09T18:52:29Z

Now more than ever, it should be clear that that the target triple does not determine the target.

+1 to that (now we just need to get rustbuild to stop trying to parse them...)

I think there should at least be an option (if not the default) to instead normalize the config JSON, hash it, and use the hash instead.

As long as this can be overridden in cargo via a flag or env var (so higher level build systems can know where files end up without hashing things themselves) that would work for me.

Ericson2314 · 2016-08-09T18:58:20Z

As long as this can be overridden in cargo via a flag or env var (so higher level build systems can know where files end up without hashing things themselves) that would work for me.

Quickly glancing over --help and the man page, I didn't see anything, but I swear this already existed.

codyps · 2016-08-09T19:02:36Z

I swear this already existed.

There is a env var to change the target directory (CARGO_TARGET_DIR, it's addition broke some of my makefiles that used a variable of the same name to track the deeper directory), but not (afaik) to change the target/<target-name> directory.

eternaleye · 2016-08-09T19:28:10Z

I'd also like to chime in supporting the idea of using TOML rather than JSON, if we make incompatible changes. IMO, it'd make it considerably easier to work with targets - in particular, the built-in targets, well-commented, could themselves serve as half-decent documentation.

cardoe · 2016-08-09T19:38:27Z

text/0000-target-bundles.md

+```js
+{
+    // REQUIRED
+    "llvm-target": "x86_64-unknown-linux-gnu",              // LLVM target triple (does not need to match with rustc triple)


Don't use dashes and instead use underscores so that you can just use #[derive(RustcEncodable, RustcDecodable)]. The dashes are the problem as I pointed out in rust-lang/rust#32988

Ericson2314 · 2016-08-09T19:49:50Z

Actually, there might be a use for all 3 autoconfig-style platforms after all. "host" for the project becomes "target" for build scripts and procedural macros.

eternaleye · 2016-08-09T19:55:53Z

@Ericson2314: Moreover, build scripts and procedural macros probably should be aware of target (consider build scripts that compile C, or procedural macros that need to care about mem::size_of<usize>())

japaric · 2016-08-09T20:15:15Z

I'd also like to chime in supporting the idea of using TOML rather than JSON, if we make incompatible changes.

It might even be possible to provide a migration path for this: Support both $TARGET.json and $TARGET.toml where the TOML spec has precedence over the JSON spec. Warn when a JSON spec is used and point to the new TOML spec. After a few cycles, ignore the JSON spec. Though I'm not sure if it's worth the trouble.

codyps · 2016-08-09T20:35:42Z

Though I'm not sure if it's worth the trouble.

Target specs have gotten members added (some mandatory) and removed as a regular occurrence, without warnings. I don't think there is really stability with the specs yet. I don't see it as a big deal to just remove the json spec support (presuming we switch toml). That said, I say this as someone using target specs with release versions, not with nightlies, so adjusting to changes here isn't so bad for me.

japaric · 2016-08-10T01:30:03Z

text/0000-target-bundles.md

+than the built-in targets rustc knows about, therefore distributing targets built-in into rustc is
+providing no benefits.
+
+Native libraries and linkers aside, it is obvious there’s little sense in distributing targets


I don't agree with this. Once "on the fly compilation of std" becomes a thing, it actually makes sense to provide all the target specifications "upfront" with rustc. Then people, specially the ones working with/on embedded systems, can choose which std features to enable/disable (e.g. remove RUST_BACKTRACE support) (*) and/or compile std with CPU specific optimizations for maximum performance (**). In this scenario, rust-std becomes a convenience to avoid the compile time required to build std the first time.

(*) This actually makes more sense for final deployments/releases.
(**) This makes sense for both development (slightly faster execution of test suites but the savings add up quickly) and for deployment to embedded systems. For releases that must work everywhere, one should instead not enable any CPU-specific optimization -- this would be the default, zero-configuration option, which is also how rust-std is compiled.

Instead of what's proposed here, I propose adding a new targets component that will be installed by rustup once regardless of which or how many toolchains (rustc components) one installs. After all, target specifications are indepedent of the host system. This also means one less step (rustup target add foo) in the initial cross compilation setup (once "on the fly compilation of std" is here).

Getting rid of precompiled std altogether isn't something I had considered in my other comments here. If we're sure that is going to happen (and as a result ${libdir}/rustlib/<target>/* is going to go away as most places that isn't writable) then it definitely makes sense to distribute specs for all supported targets at once rather than requiring them to each be downloaded separately because the size of a target will just be the size of it's spec.

After all, target specifications are indepedent of the host system.

They aren't independent of the compiler however, as the fields will probably be subject to change for a while.

You are right. Then we could use the same "channel" policy that the toolchain uses. If you do rustup update nightly, you get an updated targets-nightly; If you do rustup default stable, you get targets-stable; and so for.

I do not disagree with any points raised here, but I feel like solving this concern should become a part of eventual “custom std on demand” RFC, which AFAICT not even feasible at the moment due to stability concerns.

nagisa added 2 commits August 9, 2016 17:14

Add target bundles

f73b4a1

Add target inspection as motivation

86143d2

Amanieu reviewed Aug 9, 2016
View reviewed changes

codyps reviewed Aug 9, 2016
View reviewed changes

json → js

68aa1d2

cardoe reviewed Aug 9, 2016
View reviewed changes

alexcrichton added the T-dev-tools Relevant to the development tools team, which will review and decide on the RFC. label Aug 9, 2016

japaric reviewed Aug 10, 2016
View reviewed changes

japaric mentioned this pull request Aug 16, 2016

rust should not assume NEON on armhf rust-lang/rust#35590

Closed

Ericson2314 mentioned this pull request Aug 19, 2016

Enable customizing the linkage of a platform's C runtime #1721

Merged

Conversation

nagisa commented Aug 9, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codyps commented Aug 9, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nagisa Aug 9, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

codyps Aug 9, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nagisa commented Aug 9, 2016

Uh oh!

Ericson2314 commented Aug 9, 2016

Uh oh!

Ericson2314 commented Aug 9, 2016

Uh oh!

codyps commented Aug 9, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ericson2314 commented Aug 9, 2016

Uh oh!

codyps commented Aug 9, 2016

Uh oh!

eternaleye commented Aug 9, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Ericson2314 commented Aug 9, 2016

Uh oh!

eternaleye commented Aug 9, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

japaric commented Aug 9, 2016

Uh oh!

codyps commented Aug 9, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

nagisa Aug 9, 2016 •

edited

Loading

codyps Aug 9, 2016 •

edited

Loading

codyps commented Aug 9, 2016 •

edited

Loading

eternaleye commented Aug 9, 2016 •

edited

Loading

codyps commented Aug 9, 2016 •

edited

Loading