[PATCH] Adds a CMake package configuration file for libclang

Manuel Klimek klimek at google.com
Wed Mar 6 07:01:32 PST 2013


Hi Damien,

for the future: it'll be easier to get your patches reviewed if you don't
directly address a single dev (in this case Chandler, whose review queue is
constantly over-subscribed anyway).

Looking at your patch, it generally looks good if the high level direction
is right... I'm cc'ing Brad King, who has responded to your original pull
request, in the hope that he can confirm that this looks good from a cmake
perspective.

The other question is that I think that there are still many (basically
all) package releases that use the configure-based build. We'll need a
solution for those as well. Is the idea that we just copy the correctly
versioned files into <prefix>/share/clang/cmake? If yes, how does cmake
find them there?

Cheers,
/Manuel


On Wed, Mar 6, 2013 at 6:26 AM, Damien Buhl <damien.buhl at lecbna.org> wrote:

> Dear llvm maintainers,
>
> I'm writing you in order to get, if possible, a review of this small
> patch, because I sent this patch since two weeks and I didn't get any reply.
>
> I was wondering if this was a problem with the patch, that it doesn't seem
> relevant, has no priority or if simply you didn't got the time to take a
> look at it.
>
> As a consequence I'm just sending this mail to notify of the existence of
> my patch and waiting for a review.
>
>
> Cheers,
> --
> Damien Buhl
> alias daminetreg
>
> On 02/22/2013 01:51 AM, Damien Buhl wrote:
>
>> Dear Chandler Carruth,
>>
>> I forgot one single line (didn't add it to the git commit) in the
>> previous patch to include the change I made to the CMakeLists.txt of
>> libclang which performs the add_subdirectory of the cmake/modules
>> CMakeLists.txt.
>>
>> Please find the updated patch attached.
>>
>> Cheers,
>> --
>> Damien Buhl
>> alias daminetreg
>>
>> On 02/22/2013 01:27 AM, Damien Buhl wrote:
>>
>>> Dear Chandler Carruth,
>>>
>>> I'm sending you a patch today, which adds a CMake package configuration
>>> file for libclang. So that others CMake based project can easily find
>>> libclang and link to it, as we are used to with CMake :
>>>
>>>  find_package(libclang 3.2 REQUIRED)
>>>> link_directories(${LIBCLANG_**LIBRARY_DIRS})
>>>> include_directories(${**LIBCLANG_INCLUDE_DIRS})
>>>> add_definitions(${LIBCLANG_**DEFINITIONS})
>>>>
>>>
>>> I'm sending you this patch, because I first proposed a FindLibClang to
>>> the CMake project, but as Brad King from Kitware told me that it would
>>> be better for libclang to provide a package configuration file; I
>>> decided to drop my FindLibClang (See the pull request :
>>> https://github.com/Kitware/**CMake/pull/34<https://github.com/Kitware/CMake/pull/34>
>>> ).
>>>
>>> The patch simply adds a configuration and install step for
>>> libclang-config.cmake and libclang-config-version.cmake.
>>>
>>> The libclang-config.cmake provides the LIBCLANG_INCLUDE_DIRS,
>>> LIBCLANG_LIBRARY_DIRS, LIBCLANG_DEFINITIONS variables.
>>>
>>> I decided to hardcode LIBCLANG_DEFINITIONS to "-D__STDC_LIMIT_MACROS"
>>> "-D__STDC_CONSTANT_MACROS", instead of using something like list(APPEND
>>> @LLVM_DEFINITIONS@ ...), because I think it's the more correct decision
>>> since clang is a separate project based on llvm, but isn't fully part of
>>> it (i.e. Neither the same git repository nor a git submodule of llvm).
>>>
>>> That's why I made the supposition that it's not set in stone that both
>>> llvm and clang will always share the same #defines in the future.
>>> Perhaps I misinterpreted something here, so don't hesitate to ask me to
>>> change this to the non hardcoded variant.
>>>
>>> The other file libclang-config-version.cmake simply checks that the
>>> requested version is totally exact (major and minor) to the one of the
>>> installed library. It's currently checking for exact equality, because I
>>> didn't find anything in the documentation telling that the API stays
>>> backward compatible accross minor versions. Is it the case ?
>>>
>>> On our side we are already using this patch to integrate libclang in our
>>> build. We use libclang as a c++ parser for a tool generating interfaces
>>> and bindings between different programming languages. Until now we were
>>> using gcc plugins to extract the information from c++ code, but it was
>>> such a hell of macros and of #pragma poison, that we wanted to change to
>>> something cleaner, and libclang has a so nice API, that we moved.
>>>
>>> Thank you alot for the nice work done on llvm and clang, these projects
>>> are drastically changing the day-to-day work of many developers I
>>> know. :)
>>>
>>> Cheers,
>>> --
>>> Damien Buhl
>>> alias daminetreg
>>>
>>>
>>> ______________________________**_________________
>>> cfe-commits mailing list
>>> cfe-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/**mailman/listinfo/cfe-commits<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits>
>>>
>>>
>>
>> ______________________________**_________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/**mailman/listinfo/cfe-commits<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits>
>>
>>  ______________________________**_________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/**mailman/listinfo/cfe-commits<http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130306/222913f3/attachment.html>


More information about the cfe-commits mailing list