<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">Sure. I’m not sure if everyone will agree with me, but my general assertion is that if you’re doing a full bootstrap of a cross compiler, we’re not going to fully support that from a single CMake build tree. We didn’t support that in autoconf, so I don’t think CMake should be different in that regard. I envision bootstrapping a full cross-platform to be something like:</span><br style="font-size:12.8px"><span style="font-size:12.8px">(1) build in-tree clang<br></span><span style="font-size:12.8px">(2) build out-of-tree builtin library<br></span><span style="font-size:12.8px">(3) build out-of-tree runtime libraries</span></blockquote><div><br></div><div>This seems reasonable to me.<br>The default int-tree stuff should be for the host.<br>I don't think many will have issue with doing out of tree builds or the builtins or the runtime if they are cross compiling.<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">Today there isn’t really a simple answer. For Linux I think the bootstrap only builds for the host architecture by default. For Darwin, it builds all supported Darwin architectures, which can be complicated to determine.</span></blockquote><div>Not quite sure why IOS is built by default on darwin it should probably be OSX only and out of tree for IOS like you said above.<br>Doubt many will agree with changing this now though.<br><br></div></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="im" style="font-size:12.8px">> This might be mission creep, but it's a drag that the unspoken first<br></span><span class="im" style="font-size:12.8px">> step in developing an LLVM based toolchain is "port binutils".  I<br></span><span class="im" style="font-size:12.8px">> haven't kept watch on LLD progress, but perhaps it's far enough along<br></span><span class="im" style="font-size:12.8px">> that bootstrap process can depend on it.</span><span style="font-size:12.8px"><br></span><span style="font-size:12.8px">On Darwin ar and lld are the biggest pieces that aren’t fully featured yet. </span></blockquote><span style="font-size:12.8px"><br>Yes Darwin seems to be the biggest blocker here with the least amount of work gone into it.<br>The COFF and ELF linkers have been replaced with section based ones as that makes more sense.<br>I don't know enough about MachO to say if would be better with switching or staying with an atom based design.<br>It would be great if maybe an apple engineer more in the know would nominate them selves </span><span style="font-size:12.8px">and bring it up to par with the rest and then maybe</span><span style="font-size:12.8px"> become an OWNER.</span></div><div><span style="font-size:12.8px"><br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8px">On other platforms I think there are still places that lld isn’t fully fleshed.</span></blockquote><div>Yes there are some parts still missing and that are wip but the new COFF and ELF section based linkers should bootstrap just fine.<br><br>Just as a point for building the builtins shouldn't we just need llvm-ar ?<br>While not being feasible for the Darwin target as you said above it should be perfectly fine for windows and linux.<br>I don't think we should even need the linker to bootstrap the builtins or am I incorrect in saying this ?<br>If so I think it think it would be reasonable to have that as the mission creep.</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 3, 2015 at 12:03 AM, Chris Bieneman via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Nov 2, 2015, at 2:44 PM, Steve King <<a href="mailto:steve@metrokings.com">steve@metrokings.com</a>> wrote:<br>
><br>
> On Mon, Nov 2, 2015 at 1:02 PM, Chris Bieneman <<a href="mailto:beanz@apple.com">beanz@apple.com</a>> wrote:<br>
>> Sadly, I believe there are licensing reasons why the builtins can’t be in the LLVM repo.<br>
><br>
> Repos and licenses are orthogonal, but I get the concern.<br>
><br>
> Switching gears to other questions:<br>
> Should the bootstrap build automatically produce a built-ins library<br>
> for each target in "llvm-config --targets-built" or is the developer<br>
> expected to provide an explicit list?  Hopefully the former.<br>
<br>
</span>Today there isn’t really a simple answer. For Linux I think the bootstrap only builds for the host architecture by default. For Darwin, it builds all supported Darwin architectures, which can be complicated to determine.<br>
<span class=""><br>
><br>
> Is it reasonable that bootstrap build not depend on GNU binutils?<br>
<br>
</span>Not necessarily. To my understanding LLVM doesn’t fully replace bin utils on any platform yet, and I think we’re a long way from saying the LLVM toolchain is the default builtin toolchain.<br>
<span class=""><br>
> This might be mission creep, but it's a drag that the unspoken first<br>
> step in developing an LLVM based toolchain is "port binutils".  I<br>
> haven't kept watch on LLD progress, but perhaps it's far enough along<br>
> that bootstrap process can depend on it.<br>
<br>
</span>On Darwin ar and lld are the biggest pieces that aren’t fully featured yet. On other platforms I think there are still places that lld isn’t fully fleshed.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Chris<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
> Regards,<br>
> -steve<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>