<p dir="auto">At the moment, libstd depends for example on libnative, which itself depends on libstd. So it is not possible to compile libnative without libstd. I am not sure how rust is able to compile libstd, but I think it requires an existing libstd to compile with.</p>
<p dir="auto">My suggestion is to factor out more parts of libstd into their own crates with non-cyclic dependencies.</p>
<ul dir="auto">
<li><code class="notranslate">from_str</code>: belongs to collections, because this is where string is defined?</li>
<li><code class="notranslate">path</code>: this can be made it's own crate libpath, if we also extract some of the common macros (see below) into their own crate.</li>
<li><code class="notranslate">os</code>: this can be made it's own crate, if we somehow factor out <code class="notranslate">io::{IoResult, IoError}</code> from libstd.</li>
<li><code class="notranslate">libio</code> ?</li>
</ul>
<p dir="auto">After that, for example <code class="notranslate">libnative</code> would no longer depend on <code class="notranslate">libstd</code>. I haven't looked at other libraries, but I think it's possible too to de-cycle them.</p>
<p dir="auto">What else would need to be done?</p>
<ul dir="auto">
<li><code class="notranslate">deriving(Clone)</code> right now generates code with <code class="notranslate">::std::clone::Clone</code> while it should be <code class="notranslate">::core::clone::Clone</code>. I think this is useful in general also for other projects that solely depend on libcore. Other derivings might have to be changed to ::core as well.</li>
<li><code class="notranslate">format_args!</code>: same here.</li>
<li><code class="notranslate">libstd/macros.rs</code>: fail!, assert!, assert_eq!, debug_assert!, debug_assert_eq!, unreachable!, unimplemented!, format!, try!, vec!. They shouldn't live in libstd as they might be useful in other software that depend on libcore (plus fail functionality).</li>
</ul>
<p dir="auto">If this is something we want, I can come up with some patches. Clearly more discussion is needed IMHO.</p>
<p dir="auto">Original title: "Rewrite core::run"</p>
<p dir="auto">As per a FIXME, <code class="notranslate">// Spawn two entire schedulers to read both stdout and sterr // in parallel so we don't deadlock while blocking on one // or the other. FIXME: Surely there's a much more clever way // to do this.</code></p>