[LLVMdev] Linking Clang with an optional external library

[Óscar Fuentes]

Ryan Govostes <rzg at apple.com> writes:

> To support CMake builds as well, is it sufficient to add the following
> to config.h.cmake, and expect the user to pass -DWITH_STP_PREFIX= if
> they would like to use this feature?
>
> #cmakedefine STP_C_INTERFACE ${WITH_STP_PREFIX}/include/stp/c_interface.h

I see two problems with your approach:

* You force the user to always explicitly say where the library is
  located. On Unixy systems there are a set of well-known places where
  libraries are installed and most build systems (including the
  autotools and cmake) can fetch that library for you. The usual
  approach is to use a flag for requiring the library and an optional
  path for telling the build system where to look.

* As you mention, the part that adds the header location to the #include
  search list and the part that link the library are missing.

See r123976 (and the improvement on r128769) for an example of doing all
the above on CMake. That case is a bit more complicated than yours,
because it checks for the presence of the header file on two places and
allows independent locations for the header file and the library file,
when you only need the common prefix for both, but you can get the
idea. It also shows the required changes on config.h.cmake and the
CMakeFile(s) that adds the library to the compiler/linker invocation.

> One potential issue I noticed in writing this patch is that LLVM's
> config.h and Clang's config.h are both #include-guarded by the
> CONFIG_H macro, and consequently both cannot be included from the same
> source file. Perhaps these should be changed to LLVM_CONFIG_H and
> CLANG_CONFIG_H, respectively?

Strange indeed. CMake's build uses no guards at all on Clang's config.h
and it works fine. I wonder how the Clang config+make build works at
all. It seems that the part that source files that use the info on
Clang's config.h does not use LLVM at all, and vice-versa.