RFC: [llvm] refactor common export macros to llvm/Config

[andrurogerz]

Purpose

Eliminate code duplication in LLVM_ABI and related export macros by defining a foundational set of LLVM_INTERFACE_ macros in a new config header llvm/Config/export-config.h.

Overview

• Introduce a new export-config.h.cmake config file which contains new definitions of LLVM_INTERFACE_ macros. These macros are always defined to the appropriate export/visibility annotation.
• Move definitions controlling individual library export annotations from llvm-config.h.cmake to the new export-config.h.cmake file.
• Update LLVM_ABI macro definitions in llvm/Support/Compiler.h to alias to the new LLVM_INTERFACE_ macros, conditional on LLVM_ENABLE_LLVM_EXPORT_ANNOTATIONS being defined.
• Update 'LLVM_C_ABImacro definition inllvm-c/Visibility.hto alias toLLVM_INTERFACE_ABI, conditional on LLVM_ENABLE_LLVM_C_EXPORT_ANNOTATIONS` being defined.

Background

The effort to build LLVM as a WIndows DLL is tracked in #109483. Additional context is provided in this discourse, and documentation for LLVM_ABI and related annotations is found in the LLVM repo here.

Validation

• Built llvm-project on Windows with clang-cl and MSVC cl.
• Built llvm-project on Linux with clang and gcc.

[andrurogerz]

@compnerd this is my proposed solution to reducing preprocessor logic duplication between export macro definitions in different libraries throughout LLVM. This pattern lets us define export macros for abi-breaking.h.config like in #145575 (which was reverted) but without taking a dependency on llvm/Support/Compiler.h or duplicating a bunch of preprocessor logic.

With this patch in place, we'd be able to just use a pattern like this for any library that needs its own macros:

#if defined(LLVM_ENABLE_EXAMPLE_EXPORT_ANNOTATIONS)
#define EXAMPLE_ABI LLVM_INTERFACE_ABI
#else
#define EXAMPLE_ABI
#endif

We can even redefine the CLANG_ABI annotations this way (though I left them as-is for now).

My primary concern with this approach is that it hides the real definitions in a cmake config file making them a little harder for developers to find and understand. Do you think this is this a reasonable approach? Any other ideas/suggestions?

[compnerd]

This doesn't work. This defines the interface as to how LLVM was built. If I build LLVM dynamically, llvm-c statically, and LLVM Demangle dynamically, I need 2 independent sets of definitions for LLVM and LLVM Demangle. Doing something else really doesn't work. The de-duplication is not worth additional complexity and introducing new patterns IMO.

[andrurogerz]

The de-duplication is not worth additional complexity and introducing new patterns IMO.

I am completely on-board with the complexity argument for not doing it this way. I will put up the abi-breaking PR again with the duplicated logic.