Cpp Target CMake Overhaul

[jnhyatt]

In the C++ ANTLR target, the build system is using somewhat outdated CMake throughout. It tends to avoid modern CMake patterns in favor of older, lower-level concepts. On the other hand, it doesn't seem to do anything that modern CMake isn't capable of doing more cleanly. In addition, build files for other environments (Xcode, VS) are also present in the Cpp runtime source. This isn't ideal because CMake is a build generator designed to output build files specific to the platform and target the user chooses. Having environment-specific build files in the source tree is data duplication and must be kept up to date with each build, and in some cases (#4088), they aren't updated with releases.

A short summary of current CMake issues:

• Uses low-level environment-specific compiler flags/directories
• Macros fetch content or otherwise act as package manager
• Doesn't install targets according to FindPackage rules
• Relies on module mode (FindANTLR.cmake) rather than config mode
• Requires relatively new CMake version
• Overrides default configuration settings

I've found several issues in the project that could potentially be resolved with a CMake overhaul. In fact, in @mike-lischke's response to #3134, he mentions that the CMake files could use an overhaul. I propose (and volunteer) to redesign the Cpp target build files with the following goals:

• Port to modern CMake
• Properly configure install rules
• Simplify client-side workflow
• Maximize backwards compatibility

My current branch would change the client-side workflow outlined here to the following:

# ANTLR must be built and installed
find_package(ANTLR REQUIRED)

# antlr executable must be set in CMake or an environment variable
antlr_target(MyLexerAndParser src/MyGrammar.g4)

add_executable (MyParser src/main.cpp)

# Depend on ANTLR runtime (static or dynamic) and depend on generated parser/lexer files
target_link_libraries (MyParser
    PUBLIC
        ANTLR_MyLexerAndParser # target created by antlr_target, builds generated files
        antlr4::runtime
)

Not only is the client-side workflow dramatically more concise, it no longer clutters the client's CMake namespace with ANTLR's CMake variables. Rather than having to include files based on a variable assigned in a macro, we now simply declare a dependency on a target. Additionally, it now works with CPM:

CPMAddPackage(
    GITHUB_REPOSITORY antlr/antlr4
    VERSION 4.11.1
    SOURCE_SUBDIR runtime/Cpp
)

With these changes I hope to resolve several issues within the repo that relate to how the build system is generating the project.

[andersonjwan]

I second all of this. I have been working on a project that significantly depends on the C++ runtime of ANTLR to link my library as well as generate grammars. However, I've also found several instances of non-Modern CMake practices that clutter the build system targets and variable space that could otherwise be simplified as proposed above to give nice quality-of-life and much needed modernization of the runtime build system.

@jnhyatt If this gets approval, I would be more than happy and willing to help.

[andersonjwan]

Also, we can start collecting C++ target build system-related issues here as well. This includes #3993 regarding duplicate build steps, #2992 regarding use of old CXX standard, #3803 regarding C++17 features used in the runtime codebase but use of C++11 standard set in build system, #2539 regarding building with Visual Studio.

[Scorg]

Sorry for the bump, but I'm wondering about the status of this issue. The PR was closed seemingly due to extra modifications, and I could not find a continuation/reworked PR.