As recently discovered (see e.g. the comment at
<https://gerrit.libreoffice.org/c/core/+/163157/20#message-7952bc503fe7167156a74aed86632a458b4efb5d>
"ITEM: ItemPool Rework (I)"), our artisanal approach at implementing
--enable-pch for Clang is apparently broken.
With a stripped-down
$ cat test.h
#pragma once
struct S1 { consteval S1(int) {} };
$ cat test-pch.h
#include "test.h"
$ cat test-pch.cc
#include "test-pch.h"
$ cat test-main.cc
#include "test.h"
int main() {
struct S2 { S1 s = 0; };
S2 s;
}
the documented (at
<https://clang.llvm.org/docs/UsersManual.html#precompiled-headers>) way
of using PCH with
$ clang++ -std=c++20 -x c++-header test-pch.h -o test.pch
$ clang++ -std=c++20 -c test-main.cc -include-pch test.pch
$ clang++ test-main.o
works fine, whereas our gbuild machinery of effectively doing
$ clang++ -std=c++20 -x c++-header -Xclang -emit-pch -Xclang -fno-pch-timestamp -fpch-instantiate-templates -Xclang -building-pch-with-obj -fpch-debuginfo -fpch-codegen -c test-pch.h -o test.pch
$ clang++ -std=c++20 -c test-pch.cc -include-pch test.pch -Xclang -building-pch-with-obj -ffunction-sections -fdata-sections
$ clang++ -std=c++20 -c test-main.cc -include-pch test.pch
$ clang++ test-pch.o test-main.o
/usr/bin/ld: test-main.o: in function `main::S2::S2()':
test-main.cc:(.text+0x33): undefined reference to `S1::S1(int)'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
does not.
Maybe somebody has the inclination to dig into our artisanal approach
and fix it (I assume that would involve fixing the underlying Clang
machinery that we tap into there), or rework gbuild to use Clang's
documented PCH approach. Otherwise, I'd suggest to stick to the tried
and tested approach of not trying to use PCH in the first place...
