-
Notifications
You must be signed in to change notification settings - Fork 15
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
Conversation
My |
I forgot how `radium!` works and accidentally disabled trait production entirely on targets that have no atomics.
Macro written by Nika
This is driving me insane. I think I may actually bite the bullet and implement |
There was a problem hiding this 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.
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 inrustup 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.