We're unlikely to be making structural changes like this to the current develop branch, given that we're soon going to be switching to the code currently in addfeatures. This shouldn't be hard to adapt to addfeatures as the antlr4 integration is similar.

So retarget this PR to addfeatures or postone it after that is merged? At least can you spin the CI, because I didn't check to see if there is some implicit dependencies in there

I'll spin the CI for you and you can tweak it here, but yes this will likely need to be retargetted to addfeatures if you want a chance at merging. addfeatures will be merged back into develop at some point.

Oh, sweet Jesus, I'll try to clean up the flake8 stuff today. That's always getting more picky without our intervention.

I cleaned up the rot, for now just in develop. Rebase onto those changes and see if you can make it work with the CI. I'll port this stuff over to addfeatures soon (some of it was already there).

I should probably make one thing explicit given the likely motives for this, and in reference to #1407 .

This seems to be in the spirit of "make it easy to dynamically link Antlr4, probably on Linux installations". In theory that's fine. In practice, the runtime is tightly linked to the version of Antlr used to generate the parser, and we are not going to abstract that as part of the build process, based on prior experience with how Antlr4 is sub-versioned.

So, a given release of AFDKO will be tied to a given, very specific Antlr4 Cpp runtime, based on the generated parser files, and will typically run several versions behind the current one.

Various distro maintainers think they want to dynamically link the Antlr4 Cpp runtime into AFDKO. What they will discover they really want is to link what they consider to be current version of the Antlr4 Cpp runtime, and they'll start filing issues here requesting that we either "optionally" rebuild the parser as part of the build process, or just adjust the runtime according to what they think is current.

We're not going to do either of those things.

If people want to dynamically link the runtime, fine, they can do that. But they'll have to dynamically link the matching version, even if no one else uses that version in the entire distro, which is likely to be the case most of the time, given that Antlr4 isn't all that widely used. So the shared library will largely be a false economy, just creating work for the distros with little to no actual benefit.

Looks like the lack of an independent build combined with CMake's general pattern of "first to set a variable wins" means that AFDKO configuration (such as C++ version) may be overriding Antlr4 configuration.

So, a given release of AFDKO will be tied to a given, very specific Antlr4 Cpp runtime, based on the generated parser files, and will typically run several versions behind the current one.

That is perfectly acceptable. Would you want the restriction to be at build time or runtime? From the distro side, if there is a build time restriction, usually these will raise FTBFS (fail to build from source) issues and would be addressed appropriately on their side (bumping packages, adding compatibility layers, etc.)

There are 2 main benefits for allowing shared library linking for distros:

• Reducing binary size
• Simplify security patching (sometimes these do not need version changes)

That said, if there are reasonable concerns for upstream to build with static linking, we do accomodate to that workflow and package the static libraries as well.

Looks like the lack of an independent build combined with CMake's general pattern of "first to set a variable wins" means that AFDKO configuration (such as C++ version) may be overriding Antlr4 configuration.

I'll try to investigate it. Agh, these are added via include instead of add_subdirectory. Would you be ok with a slight reorganization to have a /third_party/antlr4/CMakeLists.txt structure so that add_subdirectory can be used? Otherwise it might require using block which is rquiring CMake 3.25

I'll try to investigate it. Agh, these are added via include instead of add_subdirectory. Would you be ok with a slight reorganization to have a /third_party/antlr4/CMakeLists.txt structure so that add_subdirectory can be used?

Possibly, but I think then you'd be on the hook for restructuring the other two as well, at least to the point of having a parallel structure.

Reducing binary size

This makes a number of assumptions, in this case the main one being that a statistically significant (e.g. > 0) number of other packages will be using the same specific version of the Cpp runtime. If not, with a dynamic library you're keeping all of the code around in contrast with static linking, which will pull in only the function chains that are actually used.

Possibly, but I think then you'd be on the hook for restructuring the other two as well

Sure, I had the LibXml2 change staged locally. But other two? Am I missing one outside LibXml2 and antlr4?

Reducing binary size

This makes a number of assumptions, in this case the main one being that a statistically significant (e.g. > 0) number of other packages will be using the same specific version of the Cpp runtime. If not, with a dynamic library you're keeping all of the code around in contrast with static linking, which will pull in only the function chains that are actually used.

Of course, this is decided a case-by-case, and since the current Fedora setup builds antlr4 as static, I will continue to use that approach until other dependencies appear. I have added the shared library support because the build was already there, but if you prefer to remove that support, I am perfectly ok with doing that, especially since adding it back in is trivial and can be done as a need arises.

But other two?

My mistake -- I remembered there were three files in the cmake directory but forgot one of them was the sanitizer code.

I have added the shared library support because the build was already there, but if you prefer to remove that support, I am perfectly ok with doing that, especially since adding it back in is trivial and can be done as a need arises.

The functionality is fine, and I think we can live with the attractive nuisance aspect.