Make header-only builds work from any number of translation units

[susilehtola]

The runtime generator's definitions in generators/impl/ had external
linkage, so including impl.hpp from two translation units produced
duplicate symbols. The README documented the constraint honestly --
include it "exactly once per project" -- but that is not something a
downstream project can enforce across its own dependencies.

Marking the definitions unconditionally inline does not work either: an
inline function that is not odr-used in a translation unit is never
emitted, so the precompiled libintegratorxx would export nothing and the
default build would fail to link. The two modes genuinely want different
linkage, and the whole point of the precompiled default is to keep the
large angular dispatch out of consumer translation units.

Give them different linkage explicitly:

• INTEGRATORXX_GENERATOR_LINKAGE (impl/linkage.hpp) expands to inline
  when INTEGRATORXX_HEADER_ONLY is defined and to nothing otherwise.
• The CMake header-only branch now defines INTEGRATORXX_HEADER_ONLY on
  the interface target; previously the option only changed the target
  type, so nothing in the sources could tell the modes apart.
• In header-only mode the public generator headers include their own
  implementations at the end of the file, where the declarations are
  already visible. The impl headers include the public ones back, which
  #pragma once reduces to a no-op.
• test/lib_impl.cxx existed only to instantiate the generator once for
  the header-only test build, and is no longer needed.

impl.hpp had no include guard at all; add one.

Verified both ways: the default build still exports the generator symbols
from libintegratorxx.a and passes 9/9 tests, the header-only build passes
9/9 tests, and two translation units that both include impl.hpp now link.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01FDTFYJMQ76iujDFNHzZyXF

[wavefunction91]

See inline comments.

[wavefunction91]

With lib_impl.cxx gone, spherical_generator.cxx is the only test TU that includes generator headers, so nothing in CI links two of them, which is the property this PR fixes. Could we add a second TU directly to the spherical_generator executable in header-only mode, one that just includes the generator headers? Any definition that loses its inline linkage would then collide at link time. It needs to sit in the executable rather than in integratorxx_common_ut, since an object in a static library is only pulled in when something references it.

[susilehtola]

Added in 518c367 as test/generator_second_tu.cxx, on the executable rather than on integratorxx_common_ut for the reason you give. It only includes the three generator headers, which turns out to be enough on its own: a non-inline function with external linkage is emitted whether or not anything calls it.

Checked both directions by defining INTEGRATORXX_GENERATOR_LINKAGE to nothing in header-only mode. With the second TU the link fails on multiple definitions of angular_from_string, create_pruned_spec and robust_psi4_pruning_scheme_impl; with spherical_generator.cxx alone the same breakage still links cleanly, so the guard was indeed missing. The compiler-zoo workflow already runs both values of the option.

[wavefunction91]

Worth stating here that the choice has to be consistent across the whole link. A TU compiled without INTEGRATORXX_HEADER_ONLY sees only the declarations, and linking it against libintegratorxx while other TUs carry the inline definitions gives the same functions two definitions with different linkage, which is an ODR violation. Something like "define it in every translation unit, and don't also link the compiled library" would cover it.

[susilehtola]

Added, with the ODR reasoning spelled out: define it in every translation unit and do not also link the compiled library, because a TU compiled without it sees only the declarations.