Does not build on Linux

[zeule]

On Gentoo the build fails with:

/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lclangAST
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lclangFrontend

Both libraries do not exist in my system.

[zeule]

$ grep add_library /usr/lib/llvm/*/lib64/cmake/clang/ClangTargets.cmake
/usr/lib/llvm/13/lib64/cmake/clang/ClangTargets.cmake:add_library(clang-cpp SHARED IMPORTED)
/usr/lib/llvm/13/lib64/cmake/clang/ClangTargets.cmake:add_library(libclang SHARED IMPORTED)
/usr/lib/llvm/14/lib64/cmake/clang/ClangTargets.cmake:add_library(clang-cpp SHARED IMPORTED)
/usr/lib/llvm/14/lib64/cmake/clang/ClangTargets.cmake:add_library(libclang SHARED IMPORTED)

[zeule]

Please revert fe454e0

[zeule]

See #244.

[tannergooding]

You'll need to build https://github.com/llvm/llvm-project/tree/llvmorg-14.0.0 locally to get access to the required lib packages given they are not distributed by default in all distros or Operating Systems.

While linking against clang-cpp makes it easier for Gentoo to build "by default", it makes the experience worse on other platforms and causes the libClangSharp to no longer work by default on most platforms due to clang-cpp not being resolvable.

[zeule]

You'll need to build https://github.com/llvm/llvm-project/tree/llvmorg-14.0.0 locally

No, I don't. There was a test in #244, which prefers clang-cpp library, so linking was conditional thus making no problems for other platforms or clang builds with other options enabled. If you want to prefer the other library set, let's invert the test: if (TARGET clang-ast AND TARGET clang-frontend) (please check target names in your ClangTargets.cmake.

[tannergooding]

Dealing with n+ Linux distributions and the various quirks and oddities that each has in how they package and distribute binaries is out of scope of the project.

Referencing clang-cpp was causing many more problems than it was solving and was breaking the user experience for other "officially supported" platforms because the file wasn't resolvable by default.

The simpler thing is to simply require devs to compile libclang locally before compiling libClangSharp so that all platforms have a consistent experience and expectations. It reduces the overall risk, increases portability, and ensures that we're only relying on dynamic libraries that are available on every platform.

[zeule]

I'm afraid you are mistaken about the packaging process for Linux distributions: we strongly prefer dynamic libraries over static ones. I doubt you can find any distro without the clang-cpp .so library. Neither can I understand the mentioned problems. Referencing the clang-cpp library was under conditional test (if (TARGET clang-cpp)), thus the library has to be available to the linker when the test passes. Could you elaborate on the problems, please?

…ensures that we're only relying on dynamic libraries that are available on every platform

clangAST and clangFrontend are static libs, clang-cpp is the dynamic one.

[tannergooding]

Referencing the clang-cpp library was under conditional test (if (TARGET clang-cpp)), thus the library has to be available to the linker when the test passes

Available when the linker runs and not available at runtime for people wanting to just install a .NET tool (ClangSharpPInvokeGenerator) and then run it.

clangAST and clangFrontend are static libs, clang-cpp is the dynamic one.

Yes. The point is that libClang is itself a "standalone" DLL that exposes several imports and statically links in clangAST, clangFrontend, and friends.
libClangSharp is meant to be an extension of libClang and function in the same manner that it is "standalone" and doesn't require an existing Clang or LLVM install.

It should be sufficient to merely distribute libClang and libClangSharp SxS with the relevant tooling and for it to work.

Having libClangSharp dynamically link against clang-cpp breaks this expectation and this experience.

[zeule]

Ah, so that's what you want! Statically linked binaries! Thank you, now I understand. Then I figure we can replace the test for clang-cpp target with the opposite one for clangAST and clangFrontend and prefer them when they are available. I can submit a PR with the required changes to the CMake build script and I would appreciate if you share with me with the ClangTargets.cmake file from the Windows build of clang with the clangAST & clangFrontend static libraries, please.

[zeule]

if you share with me with theClangTargets.cmake file from the Windows build of clang with the clangAST & clangFrontend static libraries

Pardon, found one online.