search for: cmake_toolchain_file

...roject. I'm starting with this mailing list, as I see the pattern using "config-ix.cmake" a common one; it's found in all the sub-projects. For those that are not aware, in CMake the standard approach for dealing with unique toolchains, system roots, etc is through the use of a CMAKE_TOOLCHAIN_FILE variable. This toolchain file is used to define the compiler, system type, architecture, sysroot, etc. It enables a simpler, and more versatile build script. With tip of the tree on llvm and sub-projects now, when I use a toolchain file, I'm finding I have to make edits to the config-ix.cmak...

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

...lvm' with CMake. - I think this is a fundamental difference between CMake and autoconf, and people just need to get used to the difference * Bug 21570 - Cannot set default configuration options for CMake - I think you can do this in CMake by creating a toolchain file and passing it in with CMAKE_TOOLCHAIN_FILE Other issues not tracked by bugs: * FreeBSD seemed to have problems with CMake identifying itself as amd64 causing x86_64 tests to fail * Migrating buildbots * CMake builds for libc++? Thoughts? Anything missing? -Chris

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

...because they have to be "-j 1" I tried poking around (a few times). But never quite got to the bottom of how LLVM and CMake combine to handle that situation (we diverge in some odd ways from the "recommended" documented methods). Other than that it's as simple as defining CMAKE_TOOLCHAIN_FILE and letting it get on with it for the basic case. Tim.

Renato Golin <renato.golin at linaro.org> writes: > I currently use CMake+Ninja on native builds on both x86 and ARM without > problems, but I agree that cross-compilation is not yet mastered. What's wrong with cross-compilation?

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