The C++ renderer currently emits #include <nlohmann/json.hpp> in generated header-like files. Although the generated code is commonly included from many translation units, this pulls the full nlohmann/json implementation into every compile and significantly increases build time.
The existing source-style: multi-source option separates generated types, but the generated headers still depend on the full JSON header. Downstream users have to post-process the output into a forward header, a translation unit, and an implementation include fragment.
Proposal: add a C++ renderer option (for example --lean-header) that emits:
<name>Fwd.hpp: standard-library dependencies, nlohmann/json_fwd.hpp, generated types, and JSON function declarations.
<name>Fwd.cpp: includes the forward header and the full nlohmann/json.hpp, then includes the implementation fragment.
<name>.inc: non-inline JSON helper and serializer definitions.
The default output should remain unchanged. This would make the heavy JSON header a dependency of one implementation translation unit instead of every consumer of the generated types.
The C++ renderer currently emits
#include <nlohmann/json.hpp>in generated header-like files. Although the generated code is commonly included from many translation units, this pulls the full nlohmann/json implementation into every compile and significantly increases build time.The existing
source-style: multi-sourceoption separates generated types, but the generated headers still depend on the full JSON header. Downstream users have to post-process the output into a forward header, a translation unit, and an implementation include fragment.Proposal: add a C++ renderer option (for example
--lean-header) that emits:<name>Fwd.hpp: standard-library dependencies,nlohmann/json_fwd.hpp, generated types, and JSON function declarations.<name>Fwd.cpp: includes the forward header and the fullnlohmann/json.hpp, then includes the implementation fragment.<name>.inc: non-inline JSON helper and serializer definitions.The default output should remain unchanged. This would make the heavy JSON header a dependency of one implementation translation unit instead of every consumer of the generated types.