Extended to 15 October.

I am currently of two minds.

1. Archive the project.

There are lots of fine alternatives out there, and UnitTest++ does what it does. It works for the people it works for, but it really doesn't need to be worked on anymore. There are many good alternatives out there such as Catch 2, doctest, Google Test, etc. for folks that want something newer and shinier. If you need to add something to UnitTest++ for your project, you can write your own checks and reporters reasonably easily. If something doesn't quite work for your compiler, you can fork it, and that fork is cheap because the library will no longer be a moving target.

2. Reorganize the project into a two-file library (one header file, one implementation file) before starting work on it again.

The most frustrating thing about working on this project, for me, is the amount of work that goes into CMake files and autoconf files and packaging releases, etc. These just aren't things I care to spend my time on, especially since I don't use C++ on a day-to-day basis anymore. A simple two-file library eliminates this pain point, allowing myself and contributors to just focus on the core -- and it's easy to just drop two files into whatever project you are using.

If that were done, it might be interesting to try again to add in some new features, or set up CI for "weird" compilers using GitHub Actions + External Runners... or whatever. But the current state of things is an obstacle to my desire to work on UnitTest++.

A third option would be to find a new maintainer, but I've not really seen any interest when I have asked in the past, and I don't see the need.

Hiatus extended to 26 November. Comments welcome.

Forgot to unlock conversation after the previous update; unlocked now.

Thank you for your time maintaining this project and for your thoughts. I perfectly understand your frustrations with cmake, compilers, other build tools and platform differences, as that's my frustration too with my projects!

I use UnitTest++ in my projects. It has been working perfectly for me many many years and I never found any issue. The only need I once had was documentation to write a custom reporter, but I could manage. IMO the library does not need more features and, so the library maintenance could be reduced to occasional fixes to deal with new compiler checks causing compilation warnings.

Between options 1 and 2, I would prefer option 2: a solution based on a few .cpp and .h files that I could add to my projects source code. It will also have the important advantage of removing an external dependency. For you, this option will also remove all your frustrations with building tools and will allow you to continue and enjoy with this excellent project.

Thank you!

I too would like to express my gratitude for your work on this project. Being such a light weight library has been incredibly helpful to me. I too think Option 2 is a low maintenance idea. It's low overhead to include a few additional files in a project.

@pjohnmeyer, thanks for guiding the project these last couple of years. After all these years, this is still my favorite minimalist test framework for C++. I would prefer to see option 2 adopted.

@pjohnmeyer I, too, want to think you for all you have done for UT++. I started using it back in 2007. We still use it on that project I started using it on. We have had very few issues with UT++ over all these years.

FWIW,
I would prefer the see option 2 adopted.

Thanks @cecilios , @spaulaus , @SenorAgosto , and @thedrbubba for the kind words and feedback. I spent a few hours tinkering with option 2 last night and I felt somewhat reinvigorated by it. I'm not saying it's going to happen, but I'm not saying it's not going to happen.

@pjohnmeyer Thank you for UT++, have been using it for many years; it is an excellent tool for making software.
I am skeptic about making a single implementation file. Reorganizing and cleaning up the repository yes, but a single header for all the classes will make it harder to maintain but also to contribute to...
Removing autotools completely and keeping few clean simple cmakefiles would be my suggestion.

Late to a party that's long over, too, but just to make it explicit: you don't need to ever archive the project. It's fine as-is, just keep it available, please. I'm actually new to it (seen it embedded in some other prj). Looks like a nice, clean, self-containing, balanced package (with somehow a better vibe than e.g. Catch2, which I've always postponed to integrate).

As to CMake: for one, I'm reluctant to use it anyway. E.g. just cloned your stuff, did a cl -c -EHsc -std:c++17 *.cpp (plus the Win32 timing module) from muscle memory, then shoved all into a .lib and I had my first test running the next minute.

(It's quite a sight (however unsurprising) to see CMake having the superpower to kill (the spirit) of otherwise simple, straightforward, friendly projects by causing a lot more trouble than it solves.)

This was my unit test library of choice for a long time due to its simplicity. Many thanks for your contributions @pjohnmeyer .