That's Microsoft's verbiage from the GitHub repo.

Dominique Leuenberger (dimstar) - about 2 years ago

reviewer

That's no argument :)

It's finicky; wouldn't build correctly in Leap (based off the version of meson available, at the time) w/o those provisions. Could easily be possible

%meson
%meson_build

%install
%meson_install

works fine and accounts for that, but at the time what you see now is what I had to (?) do to get it working.

EDIT1: tried to use that and it complains "ERROR: Current directory is not a meson build directory: /home/abuild/rpmbuild/BUILD/DirectX-Headers-1.600.10/x86_64-suse-linux."

EDIT2: I was using it wrong ; looking @ https://fedoraproject.org/wiki/Packaging:Meson I understand what you're suggesting better. Still fails over all, but not as immediately.

EDIT3: It was just a lack of disabling the pre-testing:

%build
%meson -Dbuild-test=false
%meson_build

%install
%meson_install

works; at least for TW x86_64.

The build says this:

[   23s] ninja: Entering directory `build'
[   24s] [1/2] Compiling C++ object libDirectX-Guids.a.p/src_dxguids.cpp.o
[   24s] [2/2] Linking static target libDirectX-Guids.a

I won't pretend I know 100% what that means and/or some alternate way to handle it 🙃

A chance yes, but (with my somewhat Microsoft experience hat on) this one really isn't worth it, since it's just about 1600 bytes of static data and no code, the rest is debug info and almost 30K of ELF overhead.

Already working on it 👌

I'm not really sure what Jan is getting at though 😣w/o libDirectX-Guids.a the whole thing falls apart, iirc. I do remember fighting with that specifically back when I started with this and vaguely recall that while DirectX-Headers would technically build w/o it (I think) - Mesa build either failed or what they provided didn't result in d3d12 actually working.

Is there some sort of problem with what it's doing?

Jan Engelhardt (jengelh) - about 2 years ago

reviewer

libDirectX-Guids contains just a .rodata section and not much else. It's full of GUIDs, and the GUIDs won't be changing ever. There is no security update argument to be made for this library.

Were this all a C++ project, we'd have definitions like inline constexpr GUID IID_xyz = {0,1,2,3}; in the header file, the C++ compiler would implicitly generate (ELF) symbols whenever IID_xyz is used, and would also implicitly collapse duplicate definitions of IID_xyz again during link stages.

But you can't have nice things in C — especially not with aggregates. In a sense, dxguids could be thought of as a "header-only library", with the that half of the header being in an .a file instead of .h because of C's limitations.