Rename endian.h to portable_endian.h

[urrsk]

This change renames the endian.h file to portable_endian.h to avoid conflicts caused by circular includes. The third-party endian.h file includes the system's endian.h, which can lead to circular imports due to overlapping filenames. By renaming the file, we eliminate this issue and ensure compatibility in the CMake build process.

Finally, a macOS CI build has been added to verify that the library builds successfully on macOS, ensuring cross-platform compatibility.

---

Note

Medium Risk
Touches cross-platform build configuration and endian conversion includes used in core parsing/serialization paths; behavior is likely unchanged but misconfigured include/install paths could break downstream builds.

Overview
Fixes endian header name collisions by renaming the bundled header to 3rdparty/endian/portable_endian.h and switching internal includes from <endian.h> to <endian/portable_endian.h>; CMake include/install rules are simplified so the endian headers are installed on all platforms under include/ur_client_library/3rdparty/endian.

CI coverage is expanded with a new mac-build GitHub Actions workflow (arm64 + x86_64) and both Windows and macOS workflows now run on a nightly schedule. Tests are tightened/expanded around BinParser/PackageSerializer endian encode/decode behavior and a few assertions are corrected (e.g., EXPECT_EQ vs EXPECT_DOUBLE_EQ, explicit void casts in EXPECT_THROW).

^{Written by Cursor Bugbot for commit 2b43f21. This will update automatically on new commits. Configure here.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.22%. Comparing base (b708146) to head (2b43f21).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #442      +/-   ##
==========================================
- Coverage   75.33%   75.22%   -0.11%     
==========================================
  Files         103      103              
  Lines        5298     5304       +6     
  Branches      580      580              
==========================================
- Hits         3991     3990       -1     
- Misses        992     1000       +8     
+ Partials      315      314       -1     

Flag	Coverage Δ
start_ursim	83.33% <ø> (+0.30%)	⬆️
ur5-3.14.3	71.18% <ø> (+0.13%)	⬆️
ur5e-10.11.0	63.94% <ø> (+0.12%)	⬆️
ur5e-10.12.0	65.24% <ø> (+0.12%)	⬆️
ur5e-10.7.0	62.68% <ø> (-0.20%)	⬇️
ur5e-5.9.4	71.52% <ø> (+0.17%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[urfeex]

Looking good in general, but I don't understand why so many implementation files now need to include that header, as well as the tests. Shouldn't that be unnecessary, when only the serializer, parser and package header cpp files include it?

[gavanderhoorn]

Just a casual observer (and observation): byte swapping is often kept header only (in C/C++) to give the compiler maximum opportunity to in-line it (which can result in swaps becoming no-ops when source and target use identical order). Refactoring it into a separate shared library seems to complicate that -- unless something like LTO is used (but I'm not sure that's possible with functions from shared libraries).

Performance is probably not necessarily a concern here, but something to keep in mind perhaps (at 500 Hz there could be measurable effects).

[urrsk]

Just a casual observer (and observation): byte swapping is often kept header only (in C/C++) to give the compiler maximum opportunity to in-line it (which can result in swaps becoming no-ops when source and target use identical order). Refactoring it into a separate shared library seems to complicate that -- unless something like LTO is used (but I'm not sure that's possible with functions from shared libraries).

Performance is probably not necessarily a concern here, but something to keep in mind perhaps (at 500 Hz there could be measurable effects).

Thanks @gavanderhoorn for that point.
The motivation was to make it easier to use the library and not need to handle header dependencies that is not used in the main header

[gavanderhoorn]

@urrsk wrote:

The motivation was to make it easier to use the library and not need to handle header dependencies that is not used in the main header

but in order to be able to in-line, that header is used, right?

Is the main issue just to have to install a .h in the 3rdparty directory?

[urrsk]

@urrsk wrote:

The motivation was to make it easier to use the library and not need to handle header dependencies that is not used in the main header

but in order to be able to in-line, that header is used, right?

Is the main issue just to have to install a .h in the 3rdparty directory?

Well yes. Though this work was motivated to avoid the circular include due to the naming, and then I when all the way to avoid it in the headers to limit the overhead.
So maybe it is worth just including the header as well.

[urrsk]

I have changed the scope and reverted the cpp files approach. Thanks for the inspiration from @gavanderhoorn.
Though, kept the approach of renaming the endian.h file to avoid circular includes and simplify the CMake setup.