fix: Use the same compiler options for xrpl.libxrpl and all its submodules

[ximinez]

High Level Overview of Change

• Applies the cmake settings for the xrpl.libxrpl cmake module to the dependency modules introduced by Enforce levelization in libxrpl with CMake #5111.
• Changes the Github CI actions to build with the assert and werr options turned on. This will cause CI jobs to fail if a developer introduces a new compiler warning, or causes an assert to fail in release builds.
• Includes the OS and compiler version in the linux dependencies jobs in the "check environment" step.

Context of Change

#5111 reorganized the folders in src/libxrpl into dependencies of the xrpl.libxrpl cmake library. Unfortunately, this caused those modules to no longer have the settings that were applied to xrpl.libxrpl.

One of those settings was the -Wno-maybe-uninitialized compiler option, which resulted in new "may be used uninitialized" build warnings. When compiling with derr=TRUE, those warnings became errors, which made the build fail. The first occurence was in the "protocol" module, but there were others.

(Incidentally, this also disabled Antithesis instrumentation (#5042 #5213) in those modules.)

Type of Change

• Bug fix (non-breaking change which fixes an issue)

Before / After

Before:

1. Builds with warnings will pass CI checks.
2. Build fails when werr cmake option is enabled.

After:

1. Builds will warnings will fail some or all CI checks.
2. Build succeeds when werr cmake option is enabled.

Test Plan

This does not directly change any source code or functionality, so as long as the build works, and existing tests pass, all is well.

Suggested commit message

Use the same compiler options for all xrpl / xrpld modules    
* Resolves an issue introduced by #5111, which inadvertently removed the
      -Wno-maybe-uninitialized compiler option from some xrpl.libxrpl modules. This
      resulted in new "may be used uninitialized" build warnings, first
      noticed in the "protocol" module. When compiling with derr=TRUE, those
      warnings became errors, which made the build fail.
* Build CI jobs with "werr" set. Treats warnings as errors so the build will fail, avoiding further problems down the line.
* Also include OS and compiler information in the dependencies environment dump.

[thejohnfreeman]

Compiler options like -Wno-maybe-uninitialized were generally set on INTERFACE library Ripple::opts, which does not have that option set. I think it belongs there.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.0%. Comparing base (ff8b9aa) to head (d5bc0dd).
Report is 1 commits behind head on develop.

Additional details and impacted files

@@            Coverage Diff            @@
##           develop   #5228     +/-   ##
=========================================
- Coverage     78.0%   78.0%   -0.0%     
=========================================
  Files          789     789             
  Lines        66953   66955      +2     
  Branches      8107    8110      +3     
=========================================
- Hits         52218   52213      -5     
- Misses       14735   14742      +7     

Files with missing lines	Coverage Δ
src/xrpld/app/paths/detail/DirectStep.cpp	82.5% <100.0%> (ø)

... and 2 files with indirect coverage changes

[ximinez]

Note to self: Also need to move the UNITY_BUILD setting to Ripple::opts

Edit Turns out that target properties don't propagate to dependents the way compile definitions and options do. So I added a unity parameter to add_module. I think that doesn't break any expectations.

[Bronek]

Some minor remarks aside which are for your consideration but aren't blockers, I like this change a lot.

[ximinez]

However, I think you will like this one better, and it does compile cleanly on gcc 13 (go figure):

D'oh! What an oversight! I'll change it to [&, this, qDir], since qDir is so small.

[Bronek]

However, I think you will like this one better, and it does compile cleanly on gcc 13 (go figure):

D'oh! What an oversight! I'll change it to [&, this, qDir], since qDir is so small.

Annoyingly, this fails with gcc 13, while [&, this] compiles cleanly. Do not ask me why ¯\(ツ)/¯

../src/xrpld/app/paths/detail/DirectStep.cpp: In member function 'uint32_t ripple::DirectIPaymentStep::quality(const ripple::ReadView&, ripple::QualityDirection) const':
../src/xrpld/app/paths/detail/DirectStep.cpp:339:17: warning: possibly dangling reference to a temporary [-Wdangling-reference]
  339 |     auto const& field = [&, this, qDir]() -> SF_UINT32 const& {
      |                 ^~~~~
../src/xrpld/app/paths/detail/DirectStep.cpp:356:6: note: the temporary was destroyed at the end of the full expression '<lambda closure object>ripple::DirectIPaymentStep::quality(const ripple::ReadView&, ripple::QualityDirection) const::<lambda()>{((const ripple::DirectIPaymentStep*)this), qDir}.ripple::DirectIPaymentStep::quality(const ripple::ReadView&, ripple::QualityDirection) const::<lambda()>()'
  339 |     auto const& field = [&, this, qDir]() -> SF_UINT32 const& {
      |                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  340 |         if (qDir == QualityDirection::in)
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  341 |         {
      |         ~
  342 |             // compute dst quality in
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~
  343 |             if (this->dst_ < this->src_)
      |             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  344 |                 return sfLowQualityIn;
      |                 ~~~~~~~~~~~~~~~~~~~~~~
  345 |             else
      |             ~~~~
  346 |                 return sfHighQualityIn;
      |                 ~~~~~~~~~~~~~~~~~~~~~~~
  347 |         }
      |         ~

[ximinez]

Commit message:

fix: Use consistent CMake settings for all modules

* Resolves an issue introduced in #5111, which inadvertently removed the
  -Wno-maybe-uninitialized compiler option from some xrpl.libxrpl
  modules. This resulted in new "may be used uninitialized" build
  warnings, first noticed in the "protocol" module. When compiling with
  derr=TRUE, those warnings became errors, which made the build fail.
* Github CI actions will build with the assert and werr options turned
  on. This will cause CI jobs to fail if a developer introduces a new
  compiler warning, or causes an assert to fail in release builds.
* Includes the OS and compiler version in the linux dependencies jobs in
  the "check environment" step.
* Translates the `unity` build option into `CMAKE_UNITY_BUILD` setting.

Issues have been resolved. John is not expected to be available to follow-up.