[LLVMdev] [RFC] Progress report on CMake build system's ability to replace autoconf

[Alexey Samsonov]

On Fri, Feb 13, 2015 at 5:35 PM, Jonathan Roelofs <jonathan at codesourcery.com
> wrote:

> +alexey
>
> On 2/5/15 12:47 PM, Jonathan Roelofs wrote:
>
>>
>>
>> On 2/3/15 12:08 PM, Chris Bieneman wrote:
>>
>>> Here's the outstanding work and my (not necissarily correct) view of
>>> the status and importance of each one:
>>>
>>> * Bug 14109 - CMake build for compiler-rt should use just-built clang
>>>    - Still waiting for patches, I don't think this is a blocker
>>>
>>
> I Just discovered LLVM_BUILD_EXTERNAL_COMPILER_RT implemented by Alexey
> in https://www.mail-archive.com/cfe-commits@cs.uiuc.edu/msg91501.html
> This causes compiler-rt to be built with the just-built clang. For my
> purposes, this unblocks dropping autoconf (aside from some internal hassles
> with getting cmake built, but that's on me to deal with).
>

Right, I believe we should revisit this mode and eventually make
LLVM_BUILD_EXTERNAL_COMPILER_RT the only available option (for now it's not
the default and only runs on our buildbot). I'll see if we can workaround
the Ninja problem somehow. I also believe we should do a major rewrite of
the way this mode (and CMake build for compiler-rt) is implemented. Instead
of having a single compiler-rt build tree that would guess which
architectures the host compiler can target, and build runtimes for all of
them (which leads to "foreach(arch ${SANITIZER_COMMON_SUPPORTED_ARCH})" all
around), we might instead create one build tree for each target we support,
and pass host compiler (just-built Clang) and flags to target that
architecture (we may cross-compile) down to that  build tree. That would
drastically simplify CMake build rules. I hope I will be able to experiment
with that soon.


>
> I think it would be better if we built that way by default. What blocks
> flipping the switch so that the "build with the host compiler" behavior
> becomes opt-in? I see a note that this flag blocks using the Ninja
> generator: http://www.cmake.org/Bug/view.php?id=14771 Can that be worked
> around? Is there anything else?
>
>
> Cheers,
>
> Jon
>
>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150216/803ad542/attachment.html>