[PATCH] Adds a CMake package configuration file for libclang

[Damien Buhl]

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).
>>
>> 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
>>
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>