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

[Chris Bieneman via llvm-commits]

We have a similar problem at Apple building for iOS from OS X, and we’re seeing more or less the exact same problems you were seeing back at the dev meeting. We have workarounds that aren’t really pretty, but I’ll be working toward a real solution, because we need it to.

-Chris

> On Jan 22, 2016, at 2:06 PM, Iain Sandoe <iain at codesourcery.com> wrote:
> 
>> 
>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160122/178558eb/attachment.html>