Skip to content

Use boost-ext::ut #134

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

ClausKlein
Copy link
Collaborator

@ClausKlein ClausKlein commented Apr 14, 2025

@ClausKlein ClausKlein requested review from dietmarkuehl, camio and a team as code owners April 14, 2025 19:50
@ClausKlein ClausKlein requested review from inbal2l and wusatosi April 14, 2025 19:50
@ClausKlein ClausKlein marked this pull request as draft April 14, 2025 19:50
Copy link
Member

@dietmarkuehl dietmarkuehl left a comment

Choose a reason for hiding this comment

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

Most of the changes are OK. I'm also not objecting to the direction of using something like boost-ext.ut as a testing implementation: it is certainly an improvement over my ad hoc approach. There are, however, a number of concerns:

  1. I would like the tests to be a reasonable basis for tests of standard libraries. When I spoke to library maintainers for libstdc++ they stated that, e.g., depending in tests on <iostream> is a no go for them.
  2. Embedding the implementation rather than depending on a separate repository doesn't seem to be the direction Beman generally goes: overall there is discussion on how to support package management, e.g., to bring in a test framework like Google Test for project which wish to do so (for the reason stated above I'm also not keen on Google Test).
  3. During today's meeting (2025-04-21) I only mentioned the use of boost-ext.ut very briefly and we didn't have time to get into a discussion on what we imagine for Beman going forward. Next week at C++Now I hope to get more discussion on this topic.

I realise that only the second point is possibly actionable. On the other hand the PR doesn't change the existing tests to move to boost-ext.ut, i.e., it is more an enabling change than something which will make it hard to move into a different direction. I think my current position is that I'd land the change if the dependency were not embedded probably using FetchContent for now which is already used for project_options. Following the previous supply chain attack on github it is probably preferable to pull in the dependencies using a fixed SHA and update when necessary.

@ClausKlein
Copy link
Collaborator Author

First of all, at the moment this MR is a very experimental study only!

see boost-ext/ut#678

I like boost-ext::ut, but I was not expecting so much compile problems.

I will continue to analyse the tests that do not compile yet.

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.

2 participants