Skip to content

Improve the Fetch gtest workflow docs#140

Merged
steve-downey merged 5 commits intobemanproject:mainfrom
steve-downey:fetch-gtest
Mar 25, 2025
Merged

Improve the Fetch gtest workflow docs#140
steve-downey merged 5 commits intobemanproject:mainfrom
steve-downey:fetch-gtest

Conversation

@steve-downey
Copy link
Copy Markdown
Member

Pull the documentation of how to fetch GTest from github out of the details block and higher into the docs. This is will be a common workflow and should be easier to find.

Also fix a nit in the cmake module where GTest_FOUND is set for any package that is pulled in via the module.

steve-downey and others added 3 commits March 12, 2025 11:48
Remove the extra variable set.
Raise the visibility for the common case of not having a packaged googletest
available. Presets remain an open issue.
Copy link
Copy Markdown
Member

@bretbrownjr bretbrownjr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No objections from me. Let's get at least one other reviewer to take a look, though. I am not the target audience for the docs. Of course they make sense to me!

@bretbrownjr
Copy link
Copy Markdown
Member

@wusatosi in particular has opinions about how we document the ergonomics of the repo. Any thoughts about these build instructions from you, @wusatosi?

Copy link
Copy Markdown
Member

@camio camio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like having this documentation is better, but the fact that we can no longer use presets for FetchContent workflows has bit me and I expect will bite many others.

The default/simplest thing should be something that we know works (e.g. FetchContent with known versions). Using find_package and hoping the system provides something suitable is not reliable at all.

Comment thread README.md Outdated

```shell
cmake -B build -S . \
-DCMAKE_TOOLCHAIN_FILE=./cmake/gnu-toolchain.cmake \
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we include the gnu toolchain here?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The toolchain files are not designed with expectation to be use directly.
And gnu-toolchain heavily assumes the use of gnu compilers (it sets CMAKE_CXX_COMPILER to g++).
Right now direct use like this will only set CMAKE_CXX_COMPILER, maybe it would be a better idea to omit it for now.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without those toolchain files, there's no access to the sanitizer configurations we're looking at.

Of course since they're also only applied in the DEBUG configuration they aren't as likely to catch a significant number of problems when the compiler takes advantage of UB, hoists expressions, elides or inlines calls, and so forth.

Pulling the line out, though, because it's a larger discussion.

Copy link
Copy Markdown
Member

@wusatosi wusatosi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for updating the docs. I definitely prefer this.

I don't think specifying CMAKE_TOOLCHAIN_FILE is needed.

Remove the CMAKE_TOOLCHAIN_FILE in an example,  let it rely on finding a system
compiler and using that.
Copy link
Copy Markdown
Member

@wusatosi wusatosi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concern addressed.

Of course since they're also only applied in the DEBUG configuration they aren't as likely to catch a significant number of problems when the compiler takes advantage of UB, hoists expressions, elides or inlines calls, and so forth.

Pulling the line out, though, because it's a larger discussion.

I agree, I think we need to redesign our presets after the packaging stabilizes.

@steve-downey steve-downey merged commit 81b08a7 into bemanproject:main Mar 25, 2025
67 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants