Add google-highway

[WillAyd]

xref conversation with @jan-wassenberg in google/highway#2294

This intentionally does not include any of the contrib packages that are part of the CMake config

[WillAyd]

Not sure what to do with the current CI failures:

• VisualStudio-clang-cl: maybe an upstream issue with the failing test?
• MSYS2 (UCRT64) - error: '_LIBCPP_VERSION' was not declared in this scope - issue with the cpp compiler?
• MSYS2 (CLANG64) - error: undefined symbol: __truncsfbf2 - is this an issue with float16?

[jan-wassenberg]

__truncsfbf2 was an ABI breakage in llvm. This might indicate the compiler and compiler-rt packages shipped with msys2 were not matching.

The abort_test failure is:
"gtest-port.cc(859): error: Failed
Syntax error at index 16 in simple regular expression "Test Abort from [0-9]+ of abort_test.cc": '[' is unsupported."

We'll change this to use \d.

[dcbaker]

I have some general review below.

Additionally, is there a chance that upstream would take the meson.build files directly? Our preference would be to have them upstream if possible, since that tends to give a better user experience and is generally less work than us having to maintain it out of tree.

[dcbaker]

Headers are not needed here, they'll just be dropped anyway.

[WillAyd]

Sounds good - was just trying to keep this in sync with the upstream CMake configuration, but assuming that's not a big deal

[WillAyd]

Additionally, is there a chance that upstream would take the meson.build files directly? Our preference would be to have them upstream if possible, since that tends to give a better user experience and is generally less work than us having to maintain it out of tree.

I have no affiliation with google / google-highway so I'll leave that up to @jan-wassenberg

[jan-wassenberg]

Additionally, is there a chance that upstream would take the meson.build files directly? Our preference would be to have them upstream if possible, since that tends to give a better user experience and is generally less work than us having to maintain it out of tree.

hm, the interesting question is with what SLO. What we might be able to offer is to include it in our tree, and to make an effort to add new source files (in particular tests) to the meson build. But if it breaks, we won't be able to help :)

[WillAyd]

@dcbaker I'm not super familiar with MSYS2 - do you know how to resolve this issue?

2024-08-27T17:50:06.4502660Z D:/a/_temp/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/as.exe: subprojects/highway-389fbc6c0e2b91dc1aba92709b14962344915f1d/cast_test.exe.p/hwy_tests_cast_test.cc.obj: too many sections (69839)
2024-08-27T17:50:06.4503089Z D:\a\_temp\msys64\tmp\ccSBPk3T.s: Assembler messages:
2024-08-27T17:50:06.4504829Z D:\a\_temp\msys64\tmp\ccSBPk3T.s: Fatal error: can't write 152 bytes to section .text of subprojects/highway-389fbc6c0e2b91dc1aba92709b14962344915f1d/cast_test.exe.p/hwy_tests_cast_test.cc.obj: 'file too big'
2024-08-27T17:50:06.4506749Z D:/a/_temp/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/as.exe: subprojects/highway-389fbc6c0e2b91dc1aba92709b14962344915f1d/cast_test.exe.p/hwy_tests_cast_test.cc.obj: too many sections (69839)
2024-08-27T17:50:06.4508135Z D:\a\_temp\msys64\tmp\ccSBPk3T.s: Fatal error: subprojects/highway-389fbc6c0e2b91dc1aba92709b14962344915f1d/cast_test.exe.p/hwy_tests_cast_test.cc.obj: file too big
2024-08-27T17:50:06.4508213Z 

[dcbaker]

@WillAyd I'm not sure, but google suggests that -Wa,-mbig-obj might help, so adding something like:

cpp = meson.get_compiler('cpp')
add_project_arguments(cpp.get_supported_arguments(['-Wa,-mbig-obj']), language : 'cpp')

might help. If not I'll try to rope in one of the resident msys2 experts

edit: not link args, doing too many things at once :D

[WillAyd]

OK I think the meson build definition works for those now, but I am seeing this in the MSYS2 UCRT64 build:

2024-08-29T00:15:39.5808278Z Command line: `c++ D:/a/wrapdb/wrapdb/_build/meson-private/tmp6wjk2er3/testfile.cpp -o D:/a/wrapdb/wrapdb/_build/meson-private/tmp6wjk2er3/output.obj -c -D_FILE_OFFSET_BITS=64 -O0 -fpermissive` -> 1
2024-08-29T00:15:39.5809242Z stderr:
2024-08-29T00:15:39.5809752Z D:/a/wrapdb/wrapdb/_build/meson-private/tmp6wjk2er3/testfile.cpp: In function 'int main()':
2024-08-29T00:15:39.5810785Z D:/a/wrapdb/wrapdb/_build/meson-private/tmp6wjk2er3/testfile.cpp:6:17: error: '_LIBCPP_VERSION' was not declared in this scope
2024-08-29T00:15:39.5811482Z     6 |                 _LIBCPP_VERSION;

Which I don't think has anything to do with highway? Seems like an issue with the compiler in the environment?

Similarly, I don't think the CLANG64 build will be green on account of #1611 (comment)

[WillAyd]

Is there a way to skip the tests just for the windows / mysy platforms? I think the test failure in version 1.2.0 for windows is pretty pedantic, and the msys issue seems out of the control of the library