[cfe-dev] cmake & vc++: clang vs. libclang woes

[Eric Niebler]

For a few days now I've been plagued by output target conflicts between
the clang and libclang projects in Visual Studio. The errors I'm getting
look like this:

------ Build started: Project: clang, Configuration: Debug Win32 ------
  LINK : C:\boost\consulting\git\llvm\bin\Debug\clang.exe not found or
not built by the last incremental link; performing full link
     Creating library C:/boost/consulting/git/llvm/lib/Debug/clang.lib
and object C:/boost/consulting/git/llvm/lib/Debug/clang.exp
cc1as_main.obj : warning LNK4204:
'c:\boost\consulting\git\llvm\bin\debug\clang.pdb' is missing debugging
information for referencing module; linking object as if no debug info
cc1_main.obj : warning LNK4204:
'c:\boost\consulting\git\llvm\bin\debug\clang.pdb' is missing debugging
information for referencing module; linking object as if no debug info
driver.obj : warning LNK4204:
'c:\boost\consulting\git\llvm\bin\debug\clang.pdb' is missing debugging
information for referencing module; linking object as if no debug info
  clang.vcxproj -> C:\boost\consulting\git\llvm\bin\Debug\clang.exe
------ Build started: Project: c-index-test, Configuration: Debug Win32
------
c-index-test.obj : error LNK2019: unresolved external symbol
__imp__clang_equalLocations referenced in function _PrintDiagnostic
c-index-test.obj : error LNK2019: unresolved external symbol
__imp__clang_getRangeEnd referenced in function _PrintDiagnostic
c-index-test.obj : error LNK2019: unresolved external symbol
__imp__clang_getRangeStart referenced in function _PrintDiagnostic


At the very least, there is a bug in the CMake files because both these
projects try to build bin/[config]/clang.pdb. There seems to be other
conflicts too, leading to the above linker errors, but I can't track it
down. (Maybe clang.exp or clang.obj or clang.lib?)

The only workaround I've found so far is to rebuild everything from
scratch, which works only sometimes. (Parallel build causing
unpredictable results?) Any help?

Suggestion: Why not make libclang generate libclang.[dll|lib] instead of
clang.[lib|dll]? I think that would avoid these problems.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com