[llvm-dev] [CMake] CMAKE_TOOLCHAIN_FILE and projects

[Joel Winarske via llvm-dev]

Hi,

I'm working on cross-compiling llvm and sub-projects to dynamically build
Clang toolchain and associated libraries for an embedded project.

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.cmake files.  The
issue is related to re-defining CMAKE_SYSROOT and the use of; among others:

    set(CMAKE_REQUIRED_FLAGS "${CMAKE_REQUIRED_FLAGS} -nodefaultlibs")

When this flag is used in stand-alone cross-compiled builds (using
toolchain file to set the CMAKE_SYSROOT), it causes all the subsequent flag
checks to fail.

I think leveraging an implied CMake toolchain file for sub-projects should
be the preferred solution for "projects", and it's a fairly minor change to
accommodate.

Stand-alone cross-compiled example for libunwind, compiler-rt, libcxxabi,
and libcxx here (This config requires edits to the associated
config-ix.cmake files for this to work):

    https://github.com/jwinarske/flutter_embedded


Perhaps there is already a working solution to cross-compile the
sub-projects from a single build invocation now?  I found when
cross-compiling compiler-rt as part of the Clang build, it fails due to
sysroot issues.  Something which the CMake toolchain file scenario would
cleanly solve.  The end goal being, when I set the list
LLVM_TARGETS_TO_BUILD to desired targets, one could expect cross-compiled
bits (as applicable) for each sub-project.  This would greatly simplify
building a toolchain config.

Perhaps I'm not clear on the current solution, and this already does what
is needed for stand-alone cross-compiling?  Until convinced otherwise, I
think there is room for improvement here, and am willing to donate time to
address it.


Cheers,
Joel Winarske
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181227/c2334cff/attachment.html>