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
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
