antlr / antlr4

ANTLR (ANother Tool for Language Recognition) is a powerful parser generator for reading, processing, executing, or translating structured text or binary files.
http://antlr.org
BSD 3-Clause "New" or "Revised" License
17.22k stars 3.29k forks source link

Cpp Target CMake Overhaul #4102

Open jnhyatt opened 1 year ago

jnhyatt commented 1 year ago

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:

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:

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.