Hi Jim,> Perhaps I’m misunderstanding you. Are you suggesting > using QEMU as part of the LLVM build process?Just for the case of building the runtime libraries for a cross-compiled version of clang. Another option is to have the compiler-rt build depend on a host build of clang. So when cross-compiling clang, we'd generate two clang builds: a target version to ship, and a throwaway host version that only exists to cross-compile compiler-rt. I think this second option is the more elegant one (less source dependencies), but is it possible in a single CMake build? The QEMU solution entertains the idea of pushing forward with just one cross-compiler and putting all projects in one big [parallel] build. But if the QEMU dependency is too impractical, then compiler-rt requires a pre-built host cross-compiler. If no one takes issue with that, is it safe to just ignore the compiler-rt build in "autotools vs CMake" debate? It means we'll need a build to invoke the two builds. Should we write that in Make or CMake? :) -Greg On Thu, May 23, 2013 at 1:51 PM, Jim Grosbach <grosbach at apple.com> wrote:> > On May 23, 2013, at 10:30 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > > On Thu, May 23, 2013 at 6:01 AM, Jean-Daniel Dupas <devlists at shadowlab.org > > wrote: > >> If you want to build a clang version that target x86 and ARM on an x86 >> machine and your actual compiler does not support compiling for ARM, you >> have to use the just built clang. >> > > Using the just-built-clang will only work if compiler-rt has access to > each target's sysroot. Compiler-rt attempts to do this by stubbing out > sysroots (see the SDKs directory), but I wonder how well that'll work. > There's only one ARM backend, for example, but multiple ARM targets (i.e. > arm-none-linux-gnueabi, arm-linux-androideabi). Does there need to be a > separate compiler-rt for each target triple or can we get by with one per > architecture? It feels like it has to be one per target triple, but it > doesn't look to be implemented that way. I'm new to compiler-rt, but is it > possible that its CMake and autotools builds are both broken for everything > but the host target? > > > Of course, if you are building a clang version that have to run on an >> other target, you should use you current compiler. >> > > We don't need a special case for this. You can run the just-built-clang > on an emulator such as QEMU. > > > Perhaps I’m misunderstanding you. Are you suggesting using QEMU as part of > the LLVM build process? > > > -Greg > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130523/2494c78e/attachment.html>
On Thu, May 23, 2013 at 3:28 PM, Greg Fitzgerald <garious at gmail.com> wrote:> Hi Jim, > > > Perhaps I’m misunderstanding you. Are you suggesting > > using QEMU as part of the LLVM build process? > > Just for the case of building the runtime libraries for a cross-compiled > version of clang. > > Another option is to have the compiler-rt build depend on a host build of > clang. >I think you mean "build" not "host" here.> So when cross-compiling clang, we'd generate two clang builds: a target > version to ship, >I think you mean "host" not "target" here.> and a throwaway host version that only exists to cross-compile compiler-rt. >I think you mean "build" not "host" here.> I think this second option is the more elegant one (less source > dependencies), but is it possible in a single CMake build? >Right now, no, but I don't see why that's a problem. Running cmake multiple times is not difficult. Also, there's no reason to think that we need to use a just-built clang to build compiler-rt. *Any* compiler which can build compiler-rt and can target whatever platform we want runtimes for is fine, and by running cmake manually, we get to pick whichever compiler makes sense for that. Is this really a problem for which we need some kind of automation in the build system? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130523/89240523/attachment.html>
Richard Smith <richard at metafoo.co.uk> writes:>> I think this second option is the more elegant one (less source >> dependencies), but is it possible in a single CMake build? >> > > Right now, no,A CMake build can run CMake builds. This is currently done for cross-compiling LLVM: the "cross-compiling" CMake build can configure and run a nested CMake build for building a native tablegen.
> I think you mean "build" not "host" here. > I think you mean "host" not "target" here. > I think you mean "build" not "host" here.Hmm, my aim was to use LLVM terminology, not build system terminology, and there's a whole lot of overlap. I think it would have been easier to understand if I use the term "native" in place of "host" and "cross-compiled" in place of "target". As for using the term 'build' for the noun "a build, what a build tool invokes", another noun "a build variant" and a verb "to build something", I could at least use the term 'variant'. Here's the same email again! Just for the case of building the runtime libraries for a cross-compiled variant of clang. Another option is to have the compiler-rt build depend on a native variant of clang. So when cross-compiling clang, we'd generate two clang variants: a cross-compiled variant to ship, and a throwaway native variant that only exists to cross-compile compiler-rt. I think this second option is the more elegant one (less source dependencies), but is it possible in a single CMake build? The QEMU solution entertains the idea of pushing forward with just one cross-compiler and putting all projects in one big [parallel] build. But if the QEMU dependency is too impractical, then compiler-rt requires a pre-built native cross-compiler. If no one takes issue with that, is it safe to just ignore the compiler-rt build in "autotools vs CMake" debate? It means we'll need a build to invoke the two builds. Should we write that in Make or CMake? :) On Thu, May 23, 2013 at 3:48 PM, Richard Smith <richard at metafoo.co.uk>wrote:> On Thu, May 23, 2013 at 3:28 PM, Greg Fitzgerald <garious at gmail.com>wrote: > >> Hi Jim, >> >> > Perhaps I’m misunderstanding you. Are you suggesting >> > using QEMU as part of the LLVM build process? >> >> Just for the case of building the runtime libraries for a cross-compiled >> version of clang. >> >> Another option is to have the compiler-rt build depend on a host build of >> clang. >> > > I think you mean "build" not "host" here. > > >> So when cross-compiling clang, we'd generate two clang builds: a target >> version to ship, >> > > I think you mean "host" not "target" here. > > >> and a throwaway host version that only exists to cross-compile >> compiler-rt. >> > > I think you mean "build" not "host" here. > > >> I think this second option is the more elegant one (less source >> dependencies), but is it possible in a single CMake build? >> > > Right now, no, but I don't see why that's a problem. Running cmake > multiple times is not difficult. Also, there's no reason to think that we > need to use a just-built clang to build compiler-rt. *Any* compiler which > can build compiler-rt and can target whatever platform we want runtimes for > is fine, and by running cmake manually, we get to pick whichever compiler > makes sense for that. > > Is this really a problem for which we need some kind of automation in the > build system? >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130523/1da547c9/attachment.html>