Skip to content

target_family configuration #29551

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

Merged
merged 1 commit into from
Nov 7, 2015
Merged

target_family configuration #29551

merged 1 commit into from
Nov 7, 2015

Conversation

arcnmx
Copy link
Contributor

@arcnmx arcnmx commented Nov 3, 2015

Allow the changing of target_family through flexible configuration. The whole computing world isn't just a binary of *nix and Windows! Makes porting libstd and co to new platforms a lot less painful.

@rust-highfive
Copy link
Contributor

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

@sanxiyn
Copy link
Member

sanxiyn commented Nov 4, 2015

This looks good to me. Do you have any specific value in mind?

];
match &fam[..] {
"windows" | "unix" => ret.push(attr::mk_word_item(fam),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As can be seen from Travis, there is an unclosed paren here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ugh, somehow grabbed the wrong commit, will fix...

@arcnmx
Copy link
Contributor Author

arcnmx commented Nov 4, 2015

So, the most important value is actually "not unix or windows". For unique one-off platforms that don't really share implementation details with others, it's probably best to set it to "none" and then be conditional over target_os or target_env. More than anything, target_family is basically used as a shortcut or macro around a lengthy repetitive any(target_os = ...) chain, which seems to me like a workaround for the fact that we don't have the equivalent of #define (though I can think of a way or two to simulate it with macros!)

If I had my way I'd get rid of it entirely and replace it with specific things like target_feature = "pthreads" but that's a rant for another day... For now the ability to build libstd for standalone platforms without having to use a patched rustc is quite useful!

@alexcrichton
Copy link
Member

@bors: r+ efdf9aa

@bors
Copy link
Collaborator

bors commented Nov 6, 2015

⌛ Testing commit efdf9aa with merge 8f7da9a...

@bors
Copy link
Collaborator

bors commented Nov 6, 2015

💔 Test failed - auto-win-gnu-32-opt

@alexcrichton
Copy link
Member

@bors: retry

On Fri, Nov 6, 2015 at 1:11 PM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-win-gnu-32-opt
http://buildbot.rust-lang.org/builders/auto-win-gnu-32-opt/builds/2009


Reply to this email directly or view it on GitHub
#29551 (comment).

bors added a commit that referenced this pull request Nov 7, 2015
Allow the changing of `target_family` through flexible configuration. The whole computing world isn't just a binary of *nix and Windows! Makes porting `libstd` and co to new platforms a lot less painful.
@bors bors merged commit efdf9aa into rust-lang:master Nov 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants