Skip to content
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

Start working on our own version of cfg(target_has_atomic) #4

Merged
merged 13 commits into from
Sep 18, 2020

Conversation

myrrlyn
Copy link
Collaborator

@myrrlyn myrrlyn commented Sep 15, 2020

I've been unhappy with our vague guessing of what atomics are available, and the #3 issue shows a target completely outside the scope of our temporary patch.

This branch uses a build script to inspect the TARGET environment variable, which Cargo helpfully sets to the value of the --target ARCH flag. This will be one of the targets enumerated in rustup target list.

I am running this commit through the bitvec cross-compile suite. Given that this suite is extremely slow, I expect that I will update with new targets as I discover their failures.

In the meantime, I would like review on whether we think this is an appropriate solution to the problem, and how we can make the script easily accessible to users to update with their architectures as needed.

@myrrlyn myrrlyn requested a review from mystor September 15, 2020 02:26
@myrrlyn
Copy link
Collaborator Author

myrrlyn commented Sep 15, 2020

My just cross task has completed successfully with these commits. I don't feel like searching out the rest of the targets.

I forgot how `radium!` works and accidentally disabled trait
production entirely on targets that have no atomics.
@myrrlyn myrrlyn linked an issue Sep 16, 2020 that may be closed by this pull request
@myrrlyn
Copy link
Collaborator Author

myrrlyn commented Sep 16, 2020

This is driving me insane. I think I may actually bite the bullet and implement available() in the compiler just so I can throw all of this work away.

Copy link
Collaborator

@mystor mystor left a comment

Choose a reason for hiding this comment

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

If we're going to need the build script anyway, as the information isn't available from the target_arch config variable, let's just do it all in the build script. No reason to have the information split across two sources.

Sorry about asking for you to switch to using macros. I didn't realize that it wasn't possible to implement without a build script >_>

Since `radium` cannot export macros capable of precise target
detection, and build-script `cfg` entries are visible only to the
crate to which the build script belongs, `radium` target detection
must be exported some other way. The easiest way to do this is with
a type alias that is conditionally set to the atom when it exists,
and the cell when the atom is unavailable.
build.rs Outdated Show resolved Hide resolved
build.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
src/lib.rs Outdated Show resolved Hide resolved
@myrrlyn myrrlyn merged commit e963f56 into master Sep 18, 2020
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.

Unable to build on platforms without atomic types
2 participants