Open jnhyatt opened 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.
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.
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.
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:
FindPackage
rulesFindANTLR.cmake
) rather than config modeI'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:
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:
With these changes I hope to resolve several issues within the repo that relate to how the build system is generating the project.