[llvm] r346127 - [CMake] Expose opt-remark tooling through libOptRemarks.dylib

[Tom Stellard via llvm-commits]

On 01/14/2019 09:19 AM, Francis Visoiu Mistrih wrote:
> 
> 
>> On 14 Jan 2019, at 17:06, Tom Stellard <tstellar at redhat.com> wrote:
>>
>> On 12/21/2018 05:52 AM, Francis Visoiu Mistrih wrote:
>>> +CC Adam
>>>
>>>> On 20 Dec 2018, at 23:31, Tom Stellard <tstellar at redhat.com> wrote:
>>>>
>>>> On 11/05/2018 03:57 AM, Francis Visoiu Mistrih via llvm-commits wrote:
>>>>> Author: thegameg
>>>>> Date: Mon Nov  5 03:57:44 2018
>>>>> New Revision: 346127
>>>>>
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=346127&view=rev
>>>>> Log:
>>>>> [CMake] Expose opt-remark tooling through libOptRemarks.dylib
>>>>>
>>>>> * Create an install target for it
>>>>> * Add it under tools/opt-remarks
>>>>> * Add an export file for the dylib
>>>>> * Install the llvm-c/OptRemarks.h header
>>>>> * Add an API to query its version
>>>>>
>>>>
>>>
>>> Hi Tom,
>>>
>>>> Hi Francis,
>>>>
>>>> Why is this library always built as a separate shared object instead
>>>> of being part of libLLVM.so?
>>>
>>> This library is there to add support for parsing and handling opt-remarks for users outside LLVM (like opt-viewer, etc.).
>>>
>>> We obviously don’t want to have the whole libLLVM.dylib just for this use case. Are you suggesting that we use libLLVM.dylib with the right LLVM_DYLIB_COMPONENTS? I can definitely look into using that if having a separate dylib is a problem here.
>>>
>>
>> If you configure with BUILD_SHARED_LIBS=ON, then you would get a single
>> shared library for each component including libOptRemarks.  Would this
>> work for your use case?  Also, does opt-viewer need a shared library,
>> or would a static library work? It's a little unorthodox to have a special
>> case for libOptRemarks in order to get BUILD_SHARED_LIBS=ON behavior even
>> when BUILD_SHARED_LIBS is set to OFF.
> 
> I don’t think this ends in the use case of BUILD_SHARED_LIBS. We want libOptRemarks to be released as a separate shared library, the same way libLTO is. IIUC, BUILD_SHARED_LIBS=ON will make all the tools use the libraries by dynamically linking them, while in the case of libOptRemarks, LLVM tools are not using the library, but it’s meant to be used by external tools, like libLTO.
> 
> The opt-viewer is written in python, so it will need to have this as a shared library. tools/llvm-opt-report which also uses the OptRemark component links with it statically, like every other tool, unless BUILD_SHARED_LIBS is set to ON.
> 

Ok, this is a good reason to always ship a separate shared object.
Similarly libLTO.so is a shared object because it's used as
a plugin for gold.

> I believe LLVM_DYLIB_COMPONENTS was the right way to generate such a library, but last time I tried I had some issues with export files. I’ll give it a try if having a special library in tools/ is a problem. In the meanwhile if this is an issue I can put it under a cmake flag.
> 

I think what's in trunk is fine.  I really just wanted to understand
the use case, so I can make sure we package it correctly for Fedora and
also so I don't break it if I am updating the cmake files in LLVM.

-Tom 

> Thanks,
>