Improving support for CMake-based applications

[NAKAMURA Takumi]

Sorry for the delay, I committed 0002 as r201969 in the last Sunday.
I noticed it is good as the view of "clean-ups of HAVE_XXX".

I mistook the word in my previous message. s/llvm-config/LLVMBuild/.

I had thought system_libs should be handled by LLVMBuild.
Till LLVMBuild would have such a capability, I thought it'd be too
earlier to touch system_libs stuff.

I will work for llvmbuild when I had a time.

But, ... I dare to say again, ... "0002 should be a good cleanup". Thanks!

2014-02-22 0:45 GMT+09:00 Brad King <brad.king at kitware.com>:
> On 02/21/2014 10:36 AM, NAKAMURA Takumi wrote:
>> I have committed 0003 as r201852 and r201853 split.
>
> Great, thanks.  That split makes sense.
>
>> About 0002, I gave up once although I had similar changes.
>> Therefore I didn't commit it.
>> To touch this stuff, I think it'd better to redesign llvm-config and
>> llvm-config would handle system libs.
>>
>> That said, I could accept 0002 if it were required to be extensible.
>
> I don't understand what you mean.  CMake propagates library deps
> now so we can just express them in LLVMSupport (or whatever other
> libs may need them later) and everything works.
>
> Without 0002 then we have to expose enough implementation details
> in LLVMConfig.cmake to allow get_system_libs to work in application
> code, and make the applications call it.  My change makes this
> much simpler and lets CMake do the job for us.  What is wrong?
>
> -Brad
>