similar to: [LLVMdev] [RFC] Ideas on improving Compiler-RT CMake

On 6/1/15 6:42 PM, Chris Bieneman wrote: > Looping in cfe-dev because I should have send this there too from the > start. > > -Chris > >> On Jun 1, 2015, at 3:21 PM, Chris Bieneman <beanz at apple.com> >> wrote: >> >> LLVMDev, >> >> PR 15732 is the umbrella tracking the progress of making the CMake >> build system feature equivalent to

This is definitely a concern. That’s why I had proposed not treating “host” as a cross-target. Handling building compiler-rt for host differently makes one of the common cases better. WRT Ninja. Ninja’s pooling capabilities actually should solve some of the problems you’re voicing. In particular, we can make the cross-builds fall into the “console” pool to prevent ninja from over-saturating the

Hi LLVMDev, I wanted to take some time to write up and roll out a proposed road map for CMake over the next few months. Apologies in advance for the substantial 0/7 Wall of Text I've summoned here (it only cost me 3 swamp mana). The main thing I want to talk about is PR21562. For Apple PR21562 is the biggest reason we can't fully abandon autoconf. I've spent some time over the last

> On Jul 29, 2015, at 7:03 PM, Tom Stellard <tom at stellard.net> wrote: > > On Wed, Jul 29, 2015 at 01:36:43PM -0700, Chris Bieneman wrote: >> Hi LLVMDev, >> >> I wanted to take some time to write up and roll out a proposed road map for CMake over the next few months. Apologies in advance for the substantial 0/7 Wall of Text I've summoned here (it only cost

Here's the error: [ 58%] Building CXX object projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.iossim.dir/sanitizer_procmaps_mac.cc.o [ 58%] Building CXX object projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommonNoTermination.ios.dir/sanitizer_libc.cc.o [ 58%] Linking CXX shared library

> On Jul 30, 2015, at 10:30 AM, Reid Kleckner <rnk at google.com> wrote: > > On Wed, Jul 29, 2015 at 1:36 PM, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: > I wanted to take some time to write up and roll out a proposed road map for CMake over the next few months. Apologies in advance for the substantial 0/7 Wall of Text I've summoned

Sorry for the late response. You should check out CMAKE_TOOLCHAIN_FILE logic for Android platform - IIRC build rules for Android are much simpler than for Darwin/Linux, and assume that build tree will be properly configured to build a single compiler-rt runtime for a specific triple. Probably this is the approach you want to eventually use for another platforms. Also check out

Sorry I’m a little late to this thread. There has been some discussion about using CMake to generate shared libraries. Since I’ve done some patches in this area recently I thought I’d take a minute to explain the current state of things. Historically LLVM’s CMake build system has been able to produce shared libraries for each of the llvm static libraries. My patch (r220490) added the llvm-shlib

On Wed, Jul 29, 2015 at 01:36:43PM -0700, Chris Bieneman wrote: > Hi LLVMDev, > > I wanted to take some time to write up and roll out a proposed road map for CMake over the next few months. Apologies in advance for the substantial 0/7 Wall of Text I've summoned here (it only cost me 3 swamp mana). > > The main thing I want to talk about is PR21562. For Apple PR21562 is the

On Wed, Jul 29, 2015 at 1:36 PM, Chris Bieneman <beanz at apple.com> wrote: > I wanted to take some time to write up and roll out a proposed road map > for CMake over the next few months. Apologies in advance for the > substantial 0/7 Wall of Text I've summoned here (it only cost me 3 swamp > mana). > Mono black devotion ftw! Thanks for working on this. :) The main

On Wed, Jul 29, 2015 at 07:17:13PM -0700, Bob Wilson wrote: > > > On Jul 29, 2015, at 7:03 PM, Tom Stellard <tom at stellard.net> wrote: > > > > On Wed, Jul 29, 2015 at 01:36:43PM -0700, Chris Bieneman wrote: > >> Hi LLVMDev, > >> > >> I wanted to take some time to write up and roll out a proposed road map for CMake over the next few months.

> > Questions, comments, concerns, condolences? While in the process of moving away from autotools and fully supporting cmake be should look at the underlying generator to build with. I'm sure many of the llvm clang devs already use cmake with the ninja build tool provided here. http://martine.github.io/ninja/ We have an interesting issue however when we want to install a single

Cool, seems reasonable. That CMake feature request doesn't sound too onerous for them. In the meantime, the Makefile generator will have more-or-less the right job scheduling due make's job server design. Most other generators already have bad scheduling, so it isn't as interesting to have one combined build. On Thu, Jul 30, 2015 at 10:37 AM, Chris Bieneman <beanz at apple.com>

> On Jul 30, 2015, at 7:35 AM, Tom Stellard <tom at stellard.net> wrote: > > On Wed, Jul 29, 2015 at 07:17:13PM -0700, Bob Wilson wrote: >> >>> On Jul 29, 2015, at 7:03 PM, Tom Stellard <tom at stellard.net> wrote: >>> >>> On Wed, Jul 29, 2015 at 01:36:43PM -0700, Chris Bieneman wrote: >>>> Hi LLVMDev, >>>>

On Thu, Mar 20, 2014 at 10:12 PM, Greg Fitzgerald <garious at gmail.com> wrote: > > ExternalProject_Add(compiler-rt ...) > > So that was quite the experiment. Looking at > clang/runtime/CMakeLists.txt, I'm not seeing a lot of bang for buck > here, and it looks like this file is prone to bit rot. Could you please elaborate on this? In fact, I don't plan to give

Seems on OpenSUSE x86, it's called i586, not i686 :-( +Alexey: do you think we can handle this in the compiler-rt cmake files somehow? Maybe try targeting both i686 and i586 unless that would break something else? On Fri, Jul 17, 2015 at 1:31 AM, Nikola Smiljanic <popizdeh at gmail.com> wrote: > CMake Error at projects/compiler-rt/cmake/config-ix.cmake:125 (message): > Cannot

Hi Greg, On Fri, Mar 21, 2014 at 11:18 PM, Greg Fitzgerald <garious at gmail.com> wrote: > Hi Alexey, > > CMAKE_PREFIX_PATH is a convenient mechanism for exposing prebuilt > install directories to a CMake build. It contains a colon-separated > list of paths. Each path points to a directory that contains > directory names that are meaningful to CMake, including

I recently took a stab at changing the MacPorts llvm-3.4 port from the configure-based build system to the cmake-based build system. There are a couple of issues that I still haven't been able to work out yet and would like to know if these are just configuration issues on my side or bugs I should file at bugs.llvm.org: 1) libclang_rt It looks like the cmake build is missing some runtime

Building phase 2 fails on i686 Fedora 22 CMake Error at projects/compiler-rt/cmake/config-ix.cmake:125 (message): Cannot compile for i686: CMakeError.log attached On Wed, Jul 22, 2015 at 8:20 AM, Alexey Samsonov <vonosmas at gmail.com> wrote: > The problem is we "guess" that the host architecture is i686, and fail > when we find out that we can't target it (__i686__

On Jul 24, 2013, at 11:11 AM, Jeremy Huddleston Sequoia wrote: > I recently took a stab at changing the MacPorts llvm-3.4 port from the configure-based build system to the cmake-based build system. > > There are a couple of issues that I still haven't been able to work out yet and would like to know if these are just configuration issues on my side or bugs I should file at