[PATCH] D16473: Remove autoconf support for building runtime libraries.

Iain Sandoe via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 22 14:06:44 PST 2016


> On 22 Jan 2016, at 21:40, Alexey Samsonov <vonosmas at gmail.com> wrote:
> 
> samsonov added a comment.
> 
> In http://reviews.llvm.org/D16473#333957, @beanz wrote:
> 
>> Alexey,
>> 
>> My intention for leaving the makefiles for the builtins is mostly as a reference for people bootstrapping platforms, and the darwin implementation is one of the more complete implementations. I don't expect that the makefiles in their current state will cover any uses not covered by CMake. But I am aware of some use cases (specifically looking at @iains) where out-of-tree modified makefiles are the easiest path forward.
> 
> 
> I'm fine with leaving the Makefiles for builtins. But if you're removing makefiles for sanitizers, you can also remove stuff like
> 
>  FUNCTIONS.asan_osx_dynamic := $(AsanFunctions) $(AsanCXXFunctions) \
>                                $(InterceptionFunctions) \
>                                $(SanitizerCommonFunctions) \
>                                $(AsanDynamicFunctions) \
>                                $(UbsanFunctions) $(UbsanCXXFunctions)
> 
> from `make/platform/clang_darwin.mk`
> 
>> Apple's build has migrated entirely to CMake. There is one outstanding significant limitation in the CMake build system relating to bootstrapping cross-targeting builds. I'm hoping to have a solution to that in a few weeks so we can remove all the makefiles from compiler-rt.

Our concerns (codesourcery/Mentor Graphics) centre around cross-toolchains (whether in-tree or out), so a satisfactory solution to that should defuse most of those.

For example, one should hopefully be able to build a toolchain on OS X build system, intended to run on Linux host - or a toolchain intended to run on Windows host, on a Linux build system.

The alternative is to require an instance of every supported host to use as a build system for itself; that rapidly becomes unsupportable.

Iain



More information about the llvm-commits mailing list