During the vcpkg submission for Trieste 1.0.0, two issues required portfile-level workarounds that should be fixed in the Trieste source before the next release.
1. Debug headers installed to debug/include
Problem: When building with the parsers feature, cmake --install places headers into both the release and debug prefixes. vcpkg's post-build validation rejects duplicate headers under debug/include.
Current workaround (portfile):
file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/include")
Proposed fix: The parser install(FILES ...) commands in parsers/json/CMakeLists.txt and parsers/yaml/CMakeLists.txt should be gated so they don't run for debug configurations, or the header install should be moved to a shared location in the top-level CMakeLists. Alternatively, the top-level install logic could use EXCLUDE_FROM_ALL for headers in debug builds. This is a standard CMake pattern — the install(FILES) calls for headers should not run during debug-only installs.
2. No DLL export annotations on parser libraries
Problem: The json and yaml parser libraries do not use __declspec(dllexport) / __declspec(dllimport) on their public API. On Windows, when BUILD_SHARED_LIBS is ON (the vcpkg x64-windows default), MSVC does not generate an import library (.lib), so yaml.dll fails to link against json.lib:
LINK : fatal error LNK1104: cannot open file 'parsers\json\json.lib'
Current workaround (portfile):
if(VCPKG_TARGET_IS_WINDOWS)
set(VCPKG_LIBRARY_LINKAGE static)
endif()
This forces static linkage on Windows when the parsers feature is enabled, which works but prevents consumers from using shared libraries.
Proposed fix: Use CMake's GenerateExportHeader module to create export macros for both libraries:
include(GenerateExportHeader)
generate_export_header(json EXPORT_FILE_NAME json_export.h)
generate_export_header(yaml EXPORT_FILE_NAME yaml_export.h)
Then annotate the public API functions in json.h and yaml.h with the generated macros (e.g. JSON_EXPORT, YAML_EXPORT). The functions that need annotation are:
json.h: reader(), writer(), to_string(), equal(), unescape(), escape_unicode(), escape(), object(), array(), member(), parse_file(), apply_patch().
yaml.h: the corresponding public API functions.
This would allow the portfile to remove the VCPKG_LIBRARY_LINKAGE static workaround on Windows.
3. Minor: YAML_USE_CXX17 vs TRIESTE_USE_CXX17
In parsers/yaml/CMakeLists.txt, line 36 checks YAML_USE_CXX17 instead of TRIESTE_USE_CXX17. This is likely a typo — it means the YAML library always builds as C++20 regardless of the TRIESTE_USE_CXX17 option.
Summary
| Issue |
Workaround location |
Fix location |
| Debug headers |
portfile |
parsers/*/CMakeLists.txt |
| No DLL exports |
portfile (force static) |
parsers/include/trieste/json.h, yaml.h, parsers/*/CMakeLists.txt |
YAML_USE_CXX17 typo |
none |
parsers/yaml/CMakeLists.txt |
During the vcpkg submission for Trieste 1.0.0, two issues required portfile-level workarounds that should be fixed in the Trieste source before the next release.
1. Debug headers installed to
debug/includeProblem: When building with the
parsersfeature,cmake --installplaces headers into both the release and debug prefixes. vcpkg's post-build validation rejects duplicate headers underdebug/include.Current workaround (portfile):
Proposed fix: The parser
install(FILES ...)commands inparsers/json/CMakeLists.txtandparsers/yaml/CMakeLists.txtshould be gated so they don't run for debug configurations, or the header install should be moved to a shared location in the top-level CMakeLists. Alternatively, the top-level install logic could useEXCLUDE_FROM_ALLfor headers in debug builds. This is a standard CMake pattern — theinstall(FILES)calls for headers should not run during debug-only installs.2. No DLL export annotations on parser libraries
Problem: The
jsonandyamlparser libraries do not use__declspec(dllexport)/__declspec(dllimport)on their public API. On Windows, whenBUILD_SHARED_LIBSisON(the vcpkgx64-windowsdefault), MSVC does not generate an import library (.lib), soyaml.dllfails to link againstjson.lib:Current workaround (portfile):
This forces static linkage on Windows when the parsers feature is enabled, which works but prevents consumers from using shared libraries.
Proposed fix: Use CMake's
GenerateExportHeadermodule to create export macros for both libraries:Then annotate the public API functions in
json.handyaml.hwith the generated macros (e.g.JSON_EXPORT,YAML_EXPORT). The functions that need annotation are:json.h:reader(),writer(),to_string(),equal(),unescape(),escape_unicode(),escape(),object(),array(),member(),parse_file(),apply_patch().yaml.h: the corresponding public API functions.This would allow the portfile to remove the
VCPKG_LIBRARY_LINKAGE staticworkaround on Windows.3. Minor:
YAML_USE_CXX17vsTRIESTE_USE_CXX17In
parsers/yaml/CMakeLists.txt, line 36 checksYAML_USE_CXX17instead ofTRIESTE_USE_CXX17. This is likely a typo — it means the YAML library always builds as C++20 regardless of theTRIESTE_USE_CXX17option.Summary
parsers/*/CMakeLists.txtparsers/include/trieste/json.h,yaml.h,parsers/*/CMakeLists.txtYAML_USE_CXX17typoparsers/yaml/CMakeLists.txt