Jens Geyer created THRIFT-6326:
----------------------------------
Summary: Compile the compiler sources once for the executable and
the unit tests
Key: THRIFT-6326
URL: https://issues.apache.org/jira/browse/THRIFT-6326
Project: Thrift
Issue Type: Improvement
Components: Build Process
Reporter: Jens Geyer
h3. Problem
{{compiler/cpp/CMakeLists.txt}} builds {{thrift-compiler}} from the generator
sources, and {{compiler/cpp/tests/CMakeLists.txt}} builds a separate static
library {{thrift_compiler}} from the same sources, gathered a second time,
because the test executable links the generator code rather than running the
built compiler.
Measured on a Linux build configured with {{BUILD_COMPILER=ON
BUILD_LIBRARIES=OFF BUILD_TESTING=ON}}:
|| target || object files ||
| thrift-compiler (executable) | 37 |
| thrift_compiler (static library) | 35 |
| identical in both | 32 |
32 translation units are therefore compiled twice in every build. Only five
objects are unique to the executable ({{main.cc}}, {{t_kotlin}},
{{t_markdown}}, {{t_mmd}}, {{t_ocaml}}) and three to the library
({{logging.cc}} and the two test support files).
On AppVeyor this is {{thrift-compiler.exe}} at 4 min 22 s and
{{thrift_compiler.lib}} at roughly 4 min more, out of a 21 min 27 s build.
h3. Change
Compile the shared sources once into a CMake OBJECT library and let both
targets consume the objects.
{{t_ocaml_generator.cc}} stays out of the shared objects.
{{tests/ocaml/t_ocaml_generator_tests.cc}} includes that translation unit
directly, so linking a compiled copy alongside it would duplicate every
definition in it. The executable compiles that one on its own.
The standalone build of {{compiler/cpp/tests}}, which
.github/workflows/cmake.yml exercises as a separate step, keeps its current
source list. The object library is used only where that target exists, which is
the combined build.
h3. Note
In the combined build the test library gains the kotlin, markdown and mermaid
generators. {{tests/CMakeLists.txt}} carries no {{THRIFT_ADD_COMPILER}} entry
for those three while the parent build does, so the library has been missing
them; they register themselves like every other generator. The effect is a
slightly larger test binary and one less way for the two lists to drift apart.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
