PDAL / PDAL

PDAL is Point Data Abstraction Library. GDAL for point cloud data.

Home Page:https://pdal.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Consider un-amalgamating Arbiter

valgur opened this issue · comments

The amalgamated arbiter.hpp exports a handful of extremely broadly named macros:

// //////////////////////////////////////////////////////////////////////
// Beginning of content of file: arbiter/util/macros.hpp
// //////////////////////////////////////////////////////////////////////
#pragma once
#define ROTLEFT(a,b) (((a) << (b)) | ((a) >> (32-(b))))
#define ROTRIGHT(a,b) (((a) >> (b)) | ((a) << (32-(b))))
// SHA256.
#define CH(x,y,z) (((x) & (y)) ^ (~(x) & (z)))
#define MAJ(x,y,z) (((x) & (y)) ^ ((x) & (z)) ^ ((y) & (z)))
#define EP0(x) (ROTRIGHT(x,2) ^ ROTRIGHT(x,13) ^ ROTRIGHT(x,22))
#define EP1(x) (ROTRIGHT(x,6) ^ ROTRIGHT(x,11) ^ ROTRIGHT(x,25))
#define SIG0(x) (ROTRIGHT(x,7) ^ ROTRIGHT(x,18) ^ ((x) >> 3))
#define SIG1(x) (ROTRIGHT(x,17) ^ ROTRIGHT(x,19) ^ ((x) >> 10))
// MD5.
#define F(x,y,z) ((x & y) | (~x & z))
#define G(x,y,z) ((x & z) | (y & ~z))
#define H(x,y,z) (x ^ y ^ z)
#define I(x,y,z) (y ^ (x | ~z))
#define FF(a,b,c,d,m,s,t) { a += F(b,c,d) + m + t; \
a = b + ROTLEFT(a,s); }
#define GG(a,b,c,d,m,s,t) { a += G(b,c,d) + m + t; \
a = b + ROTLEFT(a,s); }
#define HH(a,b,c,d,m,s,t) { a += H(b,c,d) + m + t; \
a = b + ROTLEFT(a,s); }
#define II(a,b,c,d,m,s,t) { a += I(b,c,d) + m + t; \
a = b + ROTLEFT(a,s); }

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 🤷.

#4334 removes the macros in Arbiter that were causing trouble.
#4335 updates PDAL to Eigen 3.4

Happy to merge a PR that optionally used an external Eigen (but used the vendored one by default).

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!