libe3.pc's Cflags (as of #70) exports -DLATREC_DEFAULT_DIR="<path>" as a quoted string macro when libe3 was built with LIBE3_ENABLE_LATREC=ON and LIBE3_BUILD_TESTS=ON — the latter is the option() default, so this is what a consumer gets by following the plain documented build.
pkg-config's own Cflags tokenizer does not preserve the embedded double quotes. Verified directly, no CMake involved:
$ pkg-config --cflags libe3
-I/.../include -DLIBE3_ENABLE_JSON -DLIBE3_ENABLE_ASN1 -DLIBE3_HAS_ZMQ=1 -DLIBE3_ENABLE_LATREC -DLATREC_DEFAULT_DIR=/.../libe3-build/latrec
The quotes around the path are gone. Since LATREC_DEFAULT_DIR is consumed by latrec.h as a C string literal (static const char* dir = LATREC_DEFAULT_DIR; or similar), the unquoted path is spliced directly into source text at the -D site. If the path happens to contain a run of hex-looking digits immediately followed by a letter (e.g. a hash-like build directory name), the preprocessor/compiler parses it as a malformed numeric literal with a user-defined-literal suffix:
error: unable to find numeric literal operator 'operator""XXXX'
— a hard, unexplained compile break for any downstream project that consumes libe3 through pkg-config with LIBE3_BUILD_TESTS=ON at libe3's own build time. Confirmed present/absent by build option: -DLIBE3_BUILD_TESTS=OFF at libe3's configure time removes LATREC_DEFAULT_DIR from the exported Cflags entirely (its emission is gated on LIBE3_BUILD_TESTS in cmake/libe3Options.cmake), so the bug only manifests with the default test-build configuration.
Two separable issues, either of which would fix this:
LATREC_DEFAULT_DIR is a path into libe3's own build tree (${CMAKE_BINARY_DIR}/latrec), set for libe3's own test suite. It has no meaning to a downstream consumer and arguably shouldn't be part of the installed package's public interface at all.- If it is kept, it needs to survive
.pc Cflags transport — which for an embedded string literal means either not quoting it in the .pc.in template (relying on the compiler's own -D semantics, which typically treat -DFOO=bar where bar is unquoted as a bare token, not a string, so latrec.h's use-site would need #FOO stringizing instead) or accepting that a value needing to remain a quoted string cannot round-trip through a .pc file's Cflags field without a consumer-side workaround.
Not blocking anything urgent on the reporting side — worked around downstream by simply never propagating anything matching LATREC from pkg_check_modules's variable output. Filing so the packaging fix in #70 doesn't quietly regress the next consumer who follows the plain build instructions.
libe3.pc'sCflags(as of #70) exports-DLATREC_DEFAULT_DIR="<path>"as a quoted string macro when libe3 was built withLIBE3_ENABLE_LATREC=ONandLIBE3_BUILD_TESTS=ON— the latter is theoption()default, so this is what a consumer gets by following the plain documented build.pkg-config's own Cflags tokenizer does not preserve the embedded double quotes. Verified directly, no CMake involved:
The quotes around the path are gone. Since
LATREC_DEFAULT_DIRis consumed bylatrec.has a C string literal (static const char* dir = LATREC_DEFAULT_DIR;or similar), the unquoted path is spliced directly into source text at the-Dsite. If the path happens to contain a run of hex-looking digits immediately followed by a letter (e.g. a hash-like build directory name), the preprocessor/compiler parses it as a malformed numeric literal with a user-defined-literal suffix:— a hard, unexplained compile break for any downstream project that consumes libe3 through pkg-config with
LIBE3_BUILD_TESTS=ONat libe3's own build time. Confirmed present/absent by build option:-DLIBE3_BUILD_TESTS=OFFat libe3's configure time removesLATREC_DEFAULT_DIRfrom the exported Cflags entirely (its emission is gated onLIBE3_BUILD_TESTSincmake/libe3Options.cmake), so the bug only manifests with the default test-build configuration.Two separable issues, either of which would fix this:
LATREC_DEFAULT_DIRis a path into libe3's own build tree (${CMAKE_BINARY_DIR}/latrec), set for libe3's own test suite. It has no meaning to a downstream consumer and arguably shouldn't be part of the installed package's public interface at all..pcCflags transport — which for an embedded string literal means either not quoting it in the.pc.intemplate (relying on the compiler's own-Dsemantics, which typically treat-DFOO=barwherebaris unquoted as a bare token, not a string, solatrec.h's use-site would need#FOOstringizing instead) or accepting that a value needing to remain a quoted string cannot round-trip through a.pcfile'sCflagsfield without a consumer-side workaround.Not blocking anything urgent on the reporting side — worked around downstream by simply never propagating anything matching
LATRECfrompkg_check_modules's variable output. Filing so the packaging fix in #70 doesn't quietly regress the next consumer who follows the plain build instructions.