[LLVMdev] Deprecating autoconf/make?

[Greg Fitzgerald]

> 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>