[PATCH] Adds a CMake package configuration file for libclang
Damien Buhl
damien.buhl at lecbna.org
Thu Feb 21 16:51:50 PST 2013
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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Adds-a-CMake-package-configuration-file-for-libclang.patch
Type: text/x-patch
Size: 4481 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130222/7d4f822b/attachment.bin>
More information about the cfe-commits
mailing list