Consider un-amalgamating Arbiter
valgur opened this issue · comments
The amalgamated arbiter.hpp
exports a handful of extremely broadly named macros:
PDAL/vendor/arbiter/arbiter.hpp
Lines 3280 to 3311 in c5cd718
These are only used internally in .cpp files in non-amalgamated Arbiter, but become publicly visible in PDAL through these installed headers:
- pdal/kernels/private/PointlessLas.hpp
- pdal/io/EsriReader.hpp
- pdal/io/private/stac/Utils.hpp
- pdal/io/private/connector/Connector.hpp
Also breaks the build when trying to build PDAL with a newer non-vendored Eigen 3.4.0:
eigen3d88c0279cc26/p/include/eigen3/Eigen/src/Core/util/Meta.h:503:31: error: macro "F" requires 3 arguments, but only 1 given
503 | struct result_of<F(ArgTypes...)> {
| ^
In file included from pdal825376639aac5/b/src/io/EsriReader.hpp:44,
from pdal825376639aac5/b/src/io/EsriReader.cpp:35:
pdal825376639aac5/b/src/vendor/arbiter/arbiter.hpp:3298: note: macro "F" defined here
3298 | #define F(x,y,z) ((x & y) | (~x & z))
breaks the build when trying to build PDAL with a newer non-vendored Eigen 3.4.0:
So Eigen gets to make macros named F
but Arbiter can't? 😄
We will clean up the Arbiter leakage in the public headers. As for the private headers, well, they're private 🤷.
Also happy to merge a PR that optionally used an external laz-perf (but used the vendored one by default).
Still need to fix the leak of arbiter in pdal/io/EsriReader.hpp
FYI, for PDAL 2.7.0 I just vendored the H3 library in #4345. The reason for this is conda's packaging of H3 and py-h3 stomp over each other in regards to header files 😦.
Fixed by #4334. Thank you!