search for: cmake_

I have just committed support to llvm-ar for creating thin archives. The idea of thin archives is that they contain just the symbol table and the path to find the original .o files. By locally making thin archives the default I was able to build llvm+lld+clang with them. The total size of the .a files goes from 181,658,164 to 7,116,900 bytes. Is there any way to do that with cmake without having

The current behavior is to not specify any toolchain and invoke CMake without additional arguments for configuring the NATIVE portion of the build. However, CMake will actually set the CC, CXX, and FC environment variables to full paths of the compilers in the CMAKE_{C,CXX,Fortran}_COMPILER CMake variables inside the CMake process. This results in those variables being propagated to any execute_process calls so without explicitly providing a separate toolchain file, the configure step for the NATIVE host will pick up the compilers used by the cross-compile tool...

> CMake has undocumented variables set by the Modules/Platform/* > files to specify the rules for creating archives. These are: > > CMAKE_<LANG>_ARCHIVE_{CREATE,APPEND,FINISH} > > for creating, appending to, and finishing an archive. For > tools/platforms that do not support separate steps we also > have: > > CMAKE_<LANG>_CREATE_STATIC_LIBRARY Setting CMAKE_CXX_CREATE_STATIC_LIBRARY works on OS X and l...

On 20 July 2015 at 10:53, Brad King <brad.king at kitware.com> wrote: > On 07/20/2015 10:48 AM, Rafael Espíndola wrote: >>>> Setting CMAKE_CXX_CREATE_STATIC_LIBRARY works on OS X and linux, but >>>> on windows I still see a call to "lld-link2 /lib..." when >>>> CMAKE_CXX_CREATE_STATIC_LIBRARY is set to use llvm-lib. >> >> I was using ninja for windows too. > > Where does lld-link2 get...

On Tue, Jan 27, 2015 at 10:02 AM, Mueller-Roemer, Johannes Sebastian <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > Adding -D__MSVCRT_VERSION__=0x900 (or higher) to CMAKE_CXX_FLAGS and > -lmsvcr90 (or higher) to CMAKE_CXX_STANDARD_LIBRARIES appears to work. > -lmsvcrt80 does not work, contrary to the comment on the MinGW bug tracker. > However, if you do not have the runtimes installed, errors will occur later > on in the build process, such as: > >...

...is needed is for cmake to run >> >> .../llvm-ar cqT foo.a .... >> >> instead of >> >> .../llvm-ar cq foo.a .... > > CMake has undocumented variables set by the Modules/Platform/* > files to specify the rules for creating archives. These are: > > CMAKE_<LANG>_ARCHIVE_{CREATE,APPEND,FINISH} I went with this one on my run-cmake script, thanks. Cheers, Rafael

On 11 March 2015 at 13:06, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > So that we can drop autotools, which currently requires anyone wanting > to change the build to install an old version of autoconf, among other > pains. Having two build systems is a way bigger pain than someone > having to install cmake. Can you explain why we need to upgrade CMake to drop

...n we would need to answer is what does this get us that we *can't* get from CMake, and does that justify the burden? In your initial email you mentioned remote builds and caching. CMake supports both of these things if the underlying generator does. For many releases, CMake supports an option `CMAKE_<LANG>_COMPILER_LAUNCHER` which integrates with caching tools like ccache, and distribution tools like distcc. Personally I think the best path for a real solution to building LLVM with Bazel would likely be for CMake to get support for generating Bazel build files. That is a topic that has c...

...requiring a certain version of cmake, that would be a good discussion to > have. Saying that there might be things and that they might help isn't going > to get us anywhere. ;] >From above in this thread: -------------------------------------------------- I should also point out that CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_TARGET (both CMake 3.0 features) would make fixing compiler-rt's CMake (Bugs 14109 & 21562) a lot easier. Both of those bugs are currently blockers to depreciating the autotools build system. ------------------------------------------------- But it do...

> The Modules/Platform/Windows-MSVC.cmake module unconditionally > sets CMAKE_CXX_CREATE_STATIC_LIBRARY and uses CMAKE_LINKER. > As mentioned earlier the CMAKE_<LANG>_CREATE_STATIC_LIBRARY > and similar variables are internal implementation details > that are not meant to be set by users or project code. That > is why the above works only on certain platfor...

...; >> Can you explain why we need to upgrade CMake to drop autotools? >> > > From above in this thread: > > --------------------------------------- > From above in this thread: > > -------------------------------------------------- > I should also point out that CMAKE_SYSROOT and > CMAKE_<LANG>_COMPILER_TARGET (both CMake 3.0 features) would make > fixing compiler-rt's CMake (Bugs 14109 & 21562) a lot easier. Both of > those bugs are currently blockers to depreciating the autotools build > system. > -----------------------------------...

...ih Hsu wrote: > > > > > Just trying to understand: Are you suggesting a way to have a “-O0” > > > build without all the debug information? > > > > > Exactly. > > What is such a build useful for the average user? If changing the > default, I think that CMAKE_BUILD_TYPE=Release is what most > non-developer users want. You're probably right, in that if I just want to build e.g. clang from source because my distro package manager contains an old version and I'm not interested in hacking on it myself, then a release build makes sense. However, I...

...in newer CMake versions, that I would like to see used: CMake 2.8.10 * INTERFACE_LIBRARY (we already use this by hacking around the CMake version) CMake 2.8.11 * Targets can now have dependencies that are arbitrary files instead of just link dependencies (http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements <http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements>) * target_include_directories command (allows us to cleanup our code) * target_compile_definitions command (allows us to cleanup our code) * More updates to the Interface library features CMa...

Hi all, I'm trying to understand why LLVM uses @rpath as the install name in its dynamic libraries on macOS. This complicates the process of linking against libLLVM from third-party tools and isn't nearly as common a practice on macOS as it is on Linux. I tried tracing through history on the LLVM repo and the main thing I could find was a commit from ages ago saying that the libraries are

...;ve all earned the "Bike Shed Master Badge" today. Let me re-list all the reasons why we should move on, then all the problems of doing so, so we can base our arguments on current facts. == Pro move == 1. Using OBJECT libraries (2.8.8) has massive improvement when linking on Windows 2. CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_TARGET (3.0) would help fix compiler-rt builds 3. Ninja "pool = console" would fix the timeout issues on slow builds, but it's not clear how CMake would do that by default 4. Windows and OSX users already build by hand anyway Item (1) was alread...

Hi all, trust all is well! I was wondering if LLVM would have a Bazel integrated build in the future? I can imagine the benefits this could bring, especially with regards to remote builds and caching. I'm thinking of dumping the LLVM source-tree into my code-base and experiment with building LLVM via Bazel. Will pull requests be accepted for this? I won't mind contributing my changes

In the effort to flesh out the CMake build system a problematic issue has come up, and I’d like some feedback on how to best handle it. For reference this issue has been reported by a few users, one proposed patches that don’t really address the underlying problem here: http://reviews.llvm.org/D13131 The problem comes when bootstrapping a cross-compiler toolchain. In order to have a

> We don't require users to compile their own gcc. Are you saying it's > impossible to get pre-built CMake 2.8.12 and gcc 4.7 on either Mac or > Windows? And we wouldn't be requiring it for cmake. My point was that cmake is always easier to install: * From binaries: a bit easier, since they are provided in http://www.cmake.org/ * From source: way easier than gcc. Gosh, from

...CMake’s >> try_compile function always testing a full compile then link operation. When >> bootstrapping a cross-compiler this will always fail because linking even the >> simplest applications fails when you don’t have libclang_rt prebuilt. > > In my case, I had to use the CMAKE_{C,CXX}_COMPILER_FORCED variables and > guestimate the appropriate C/C++ flags in order to avoid CMake getting in the > way with the various checks. My scripts build clang & lld, then install the > linux's kernel & Musl's C library headers and finally build compiler-rt's...

On Sun, Sep 18, 2016 at 12:32 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> On Sep 17, 2016, at 3:19 PM, Carsten Mattner <carstenmattner at gmail.com> wrote: >> >> So, when I embark on the next ThinLTO try build, probably this Sunday, >> should I append -Wl,-plugin-opt,jobs=NUM_PHYS_CORES to LDFLAGS >> and run ninja without -j or