OPCUA-3289: New pipeline for LogIt, Refactor Build system, Clean-up old files#15
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 95fa58f68b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9115695d53
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if(DEFINED ENV{BOOST_HOME}) | ||
| message(STATUS "BOOST_HOME environment variable is set to: $ENV{BOOST_HOME}") | ||
| message(STATUS "this will set BOOST to that folder in static mode") | ||
| set(Boost_DIR $ENV{BOOST_HOME}) |
There was a problem hiding this comment.
Point
BOOST_HOME at a prefix, not Boost_DIR
When BOOST_HOME is set, this assigns it to Boost_DIR, but CMake only treats <Package>_DIR as the directory that directly contains BoostConfig.cmake. The README now documents BOOST_HOME as an install prefix, so a custom Boost under something like /opt/boost will stop configuring unless the caller knows to pass the nested lib*/cmake/Boost-* directory instead. That breaks the advertised non-system Boost flow whenever Boost lives outside the default search paths.
Useful? React with 👍 / 👎.
| tags: | ||
| - win2025-container | ||
| script: | ||
| - cmake -B build $env:CMAKE_FLAGS |
There was a problem hiding this comment.
Split Windows matrix flags before invoking CMake
In the Windows GitLab jobs this is executed by PowerShell ($env:... syntax), and PowerShell treats $env:CMAKE_FLAGS as one argument token. For the multi-backend profiles, CMake therefore receives a single malformed argument like -DLOGIT_BACKEND_STDOUTLOG=ON -DLOGIT_BACKEND_BOOSTLOG=ON, so only the first cache entry is applied and the extra backends are never enabled. As written, the new Windows matrix does not actually validate the BOOST/UATRACE/WINDOWS_DEBUGGER combinations it claims to cover.
Useful? React with 👍 / 👎.
@codex