aboutsummaryrefslogtreecommitdiff
path: root/ctru-rs/src/lib.rs
Commit message (Collapse)AuthorAgeFilesLines
* changes so that this can buildVivian Lim2021-02-051-1/+0
|
* local changesVivian Lim2021-02-011-0/+1
|
* Update for nightly-2018-08-18Fenrir2018-08-191-1/+0
|
* rename `applet` module to `applets`Fenrir2018-04-291-1/+1
|
* Initial software keyboard supportFenrir2018-04-291-0/+1
|
* Add ctru::thread moduleFenrir2018-03-171-0/+4
|
* Add Soc serviceFenrir2018-02-111-0/+1
|
* Remove rustc_private workaroundFenrir2017-07-101-3/+0
| | | | Not needed anymore with patched Xargo
* ctru-rs: workaround for xargo/sysroot issueFenrir2017-07-071-0/+3
| | | | | | | | Both our implementation of std and ctru-rs depend on the libc crate (or rather, ctru-rs depends on ctru-sys which depends on libc). This means that libc ends up both in the sysroot assembled by Xargo, as well as being built as a regular dependency for ctru-rs. However, it seems that when cargo/rustc tries to link the libc crate to ctru-rs, it first searches in the sysroot and links in the copy that it finds there, rather than the one specified in ctru-rs's Cargo.toml. rust-lang's rustbuild system does some trickery with crate metadata to avoid this sort of name collision between the sysroot and user deps, but xargo does not (yet) do something similar. And since rustc now enforces that linking to any crate from the sysroot is an unstable operation, the result is a rather cryptic compiler error. Fortunately we can work around this by simply tagging ctru-rs with #![feature(rustc_private)], but it shouldn't be regarded as a long-term fix
* ctru-rs: Add Error moduleFenrir2017-01-271-0/+3
|
* Bring in all the cratesFenrir2017-01-211-0/+18