make target-run compiled artifacts per-arch #474
Comments
ghost
assigned 
|
librustrt is written in c++. This would require a cross compiler to implement. Why do we need this? |
|
Can this be delayed until after the 0.1 milestone? |
|
Only requires a cross compiler when we support host != target. Until then it's just a question of directory organization. I agree we can defer host != target until after first milestone. I'd like to get the directory organization right though. |
|
Doing this in steps, also combining it with a slight reorg of built dirs into stageN/{bin,lib}/ such that it has the right shape to be installed into /usr/ with the RPATH-ing that has to happen in #441. First step is to teach configure and the makefiles and compiler to handle --target args, defaulting to host triple, add library search path for $sysroot/lib/rustc/$target, and make $stageN/lib/rustc/$target/ libs build along with the usual ones. Once all new stuff is building properly, snapshot and start purging the old stuff from the make system. |
|
Done. |
Fix doc generation on travis. Documentation generation appears to be failing on master (https://travis-ci.org/rust-lang/libc/jobs/183483333): ``` Collecting ghp-import Downloading ghp-import-0.4.1.tar.gz Collecting travis Could not find a version that satisfies the requirement travis (from versions: ) No matching distribution found for travis ``` Basically `--user` doesn't appear to take an option, so `pip install ghp_import --user $USER` makes pip think the user is a package that needs to be installed (in this case `travis`). As there is no `travis` package, it dies.
In [RFC rust-lang#474][rfc474], the issue of how to handle Displaying a Path was left as an open question. The problem is that a Path may contain non-UTF-8 data on most platforms. In the implementation of the RFC, a `display` method was added, which returns an adapter that implements `Display` by replacing non-UTF8 data with a unicode replacement character. Though I can't find a record of the discussion around this issue, I believe there were two primary reasons not to just implement this behavior as the `Display` impl of `Path`: 1. The adapter allocated in the non-UTF8 case, and Rust as a rule tries to avoid allocations that are not explicit in code. 2. The user may prefer an alternative solution than using the unicode replacement character for handling non-UTF8 data. In my view, the choice to provide an adapter rather than implement Display has had a high cost in terms of user experience: * I almost never remember that I need an adapter, forcing me to go back and edit my code after compiling it and getting an error. * It makes my code more noisy to have the display adapter; this detail is rarely important. * It is extremely uncommon to actually do something other than call the display adapter when trying to display a path (I have never wanted anything else myself). * For new users, it is Yet Another Compiler Error that they have to figure out how to solve, contributing to the sense that Rust nags nags and obstructs rather than assists & guides. Therefore, I think time has shown that this has been a detriment to user experience, rather than a helpful reminder. That leaves only the first reason not to implement this: implicit allocations. That problem was happily resolved in June 2017: rust-lang#42613 provided an alternative implementation which efficiently avoids allocations. Given that, I think it is time that we implement `Display` for both `Path` and `PathBuf` and deprecate the `Path::display` method. r? @alexcrichton cc @rust-lang/libs [rfc474]: https://github.com/rust-lang/rfcs/blob/master/text/0474-path-reform.md)
Fix minor typos in const functions section
* Introduce the first section of the RMC tutorial * add license boilerplate, correct typos * fix formatting
once in sysroot, librustrt.so should be built as stageN/lib/$arch/librustrt.so and recompiled for every target in the targets list for the current compiler. rustc and librustllvm should probably only be compiled for every host in the host list. Or, if we're lucky, we only have one host.
The text was updated successfully, but these errors were encountered: