Compare commits
45 commits
epel8-play
...
rawhide
| Author | SHA1 | Date | |
|---|---|---|---|
|
30879a45da | ||
|
|
8612b55400 | ||
|
|
09799363de | ||
|
|
9d2caee865 | ||
|
|
e25fdc0e2d | ||
|
|
ff69852fc2 | ||
|
|
ee4e46c601 | ||
|
|
b563fa7382 | ||
|
|
8c322233f6 | ||
|
|
4652f4a1d2 | ||
|
|
212c3c70d4 | ||
|
|
fb6c1360a5 | ||
|
45369494f3 | ||
|
|
69ad056675 | ||
|
|
67528f46ab | ||
|
f78728944b | ||
|
|
0d218cdeb6 | ||
|
|
c6606e3d5e | ||
|
|
ee7812e055 | ||
|
|
bc2566e4c4 | ||
| 482b0befd7 | |||
|
d196ad48b9 |
|||
|
|
447c37b6a4 | ||
|
154a3a8282 | ||
|
|
c043601b93 | ||
|
|
0e67d3e836 | ||
|
|
483099187a | ||
|
5fcac3f358 | ||
|
07878704fb | ||
|
|
b847f2a5a2 | ||
|
d6f3cbc43e | ||
|
|
981d3f8160 | ||
| fd1e441468 | |||
|
|
2497ae6c1c | ||
|
4144359a98 | ||
|
41674ac6cd | ||
| 98fd8efc73 | |||
|
|
c760923b5c | ||
|
b1c98f414d | ||
|
|
b9706f651f | ||
| 730267c484 | |||
|
|
e391a77f5e | ||
|
|
f5ca3e365c | ||
| f4e1093f2d | |||
| c9466b24ad |
5 changed files with 510 additions and 0 deletions
7
.gitignore
vendored
7
.gitignore
vendored
|
|
@ -0,0 +1,7 @@
|
|||
/unittest-cpp-1.4-c42e68b.tar.gz
|
||||
/unittest-cpp-e76d25a01c91b38ff8a5182dd690360186136ce7.tar.gz
|
||||
/unittest-cpp-1.4-e76d25a.tar.gz
|
||||
/unittest-cpp-1.6.0-b69b63a.tar.gz
|
||||
/unittest-cpp-1.6.1-b69b63a.tar.gz
|
||||
/unittest-cpp-2.0.0-b69b63a.tar.gz
|
||||
/unittest-cpp-2.0.0.tar.gz
|
||||
12
fix_version_2.0.0.patch
Normal file
12
fix_version_2.0.0.patch
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
--- a/configure.ac
|
||||
+++ b/configure.ac
|
||||
@@ -3,7 +3,7 @@
|
||||
|
||||
AC_PREREQ([2.69])
|
||||
AC_INIT([UnitTest++],
|
||||
- m4_esyscmd_s([git describe --tags | cut -c2-]),
|
||||
+ [2.0.0],
|
||||
[pjohnmeyer@gmail.com],
|
||||
[unittest-cpp])
|
||||
|
||||
|
||||
1
sources
1
sources
|
|
@ -0,0 +1 @@
|
|||
SHA512 (unittest-cpp-2.0.0.tar.gz) = 39318f4ed31534c116679a3257bf1438a6c4b3bef1894dfd40aea934950c6c8197af6a7f61539b8e9ddc67327c9388d7e8a6f8a3e0e966ad26c07554e2429cab
|
||||
260
unittest-cpp.html
Normal file
260
unittest-cpp.html
Normal file
|
|
@ -0,0 +1,260 @@
|
|||
<html>
|
||||
<head>
|
||||
<title>UnitTest++ in brief</title>
|
||||
</head>
|
||||
<body>
|
||||
<h1>UnitTest++ in brief</h1>
|
||||
<h2>Introduction</h2>
|
||||
<p>This little document serves as bare-bones documentation for UnitTest++.</p>
|
||||
|
||||
<p>For background, goals and license details, see:</p>
|
||||
|
||||
<ul>
|
||||
<li><a href="http://unittest-cpp.sourceforge.net/">The UnitTest++ home page</a></li>
|
||||
<li><a href="http://www.gamesfromwithin.com/articles/0603/000108.html">Noel Llopis' announcement</a></li>
|
||||
</ul>
|
||||
|
||||
<p>The documentation, while sparse, aims to be practical, so it should give you enough info to get started using UnitTest++ as fast as possible.</p>
|
||||
|
||||
<h2>Building UnitTest++</h2>
|
||||
<p>Building UnitTest++ will be specific to each platform and build environment, but it should be straightforward.</p>
|
||||
|
||||
<h3>Building with Visual Studio</h3>
|
||||
<p>If you are using Visual Studio, go for either of the provided .sln files, depending on version. There are no prefabricated solutions for versions earlier than VS.NET 2003, but we have had reports of people building UnitTest++ with at least VS.NET 2002.</p>
|
||||
|
||||
<h3>Building with Make</h3>
|
||||
<p>The bundled makefile is written to build with g++. It also needs <code>sed</code> installed in the path, and to be able to use the <code>mv</code> and <code>rm</code> shell commands. The makefile should be usable on most Posix-like platforms.</p>
|
||||
|
||||
<p>Do "make all" to generate a library and test executable. A final build step runs all unit tests to make sure that the result works as expected.</p>
|
||||
|
||||
<h3>Packaging</h3>
|
||||
<p>You'll probably want to keep the generated library in a shared space in source control, so you can reuse it for multiple test projects. A redistributable package of UnitTest++ would consist of the generated library file, and all of the header files in <code>UnitTest++/src/</code> and its per-platform subfolders. The <code>tests</code> directory only contains the unit tests for the library, and need not be included.</p>
|
||||
|
||||
<h2>Using UnitTest++</h2>
|
||||
<p>The source code for UnitTest++ comes with a full test suite written <em>using</em> UnitTest++. This is a great place to learn techniques for testing. There is one sample .cpp file: <code>UnitTest++/src/tests/TestUnitTest++.cpp</code>. It covers most of UnitTest++'s features in an easy-to-grasp context, so start there if you want a quick overview of typical usage.</p>
|
||||
|
||||
<h3>Getting started</h3>
|
||||
<p>Listed below is a minimal C++ program to run a failing test through UnitTest++.</p>
|
||||
|
||||
<pre>
|
||||
// test.cpp
|
||||
#include <UnitTest++.h>
|
||||
|
||||
TEST(FailSpectacularly)
|
||||
{
|
||||
CHECK(false);
|
||||
}
|
||||
|
||||
int main()
|
||||
{
|
||||
return UnitTest::RunAllTests();
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p><code>UnitTest++.h</code> is a facade header for UnitTest++, so including that should get you all features of the library. All classes and free functions are placed in namespace <code>UnitTest</code>, so you need to either qualify their full names (as with <code>RunAllTests()</code> in the example) or add a <code>using namespace UnitTest;</code> statement in your .cpp files. Note that any mention of UnitTest++ functions and classes in this document assume that the <code>UnitTest</code> namespace has been opened.</p>
|
||||
|
||||
<p>Compiling and linking this program with UnitTest++'s static library into an executable, and running it, will produce the following output (details may vary):</p>
|
||||
|
||||
<pre>
|
||||
.\test.cpp(5): error: Failure in FailSpectacularly: false
|
||||
FAILED: 1 out of 1 tests failed (1 failures).
|
||||
Test time: 0.00 seconds.
|
||||
</pre>
|
||||
|
||||
<p>UnitTest++ attempts to report every failure in an IDE-friendly format, depending on platform (e.g. you can double-click it in Visual Studio's error list.) The exit code will be the number of failed tests, so that a failed test run always returns a non-zero exit code.</p>
|
||||
|
||||
<h3>Test macros</h3>
|
||||
<p>To add a test, simply put the following code in a .cpp file of your choice:</p>
|
||||
|
||||
<pre>
|
||||
TEST(YourTestName)
|
||||
{
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>The <code>TEST</code> macro contains enough machinery to turn this slightly odd-looking syntax into legal C++, and automatically register the test in a global list. This test list forms the basis of what is executed by <code>RunAllTests()</code>.</p>
|
||||
|
||||
<p>If you want to re-use a set of test data for more than one test, or provide setup/teardown for tests, you can use the <code>TEST_FIXTURE</code> macro instead. The macro requires that you pass it a class name that it will instantiate, so any setup and teardown code should be in its constructor and destructor.</p>
|
||||
|
||||
<pre>
|
||||
struct SomeFixture
|
||||
{
|
||||
SomeFixture() { /* some setup */ }
|
||||
~SomeFixture() { /* some teardown */ }
|
||||
|
||||
int testData;
|
||||
};
|
||||
|
||||
TEST_FIXTURE(SomeFixture, YourTestName)
|
||||
{
|
||||
int temp = testData;
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>Note how members of the fixture are used as if they are a part of the test, since the macro-generated test class derives from the provided fixture class.</p>
|
||||
|
||||
<h3>Suite macros</h3>
|
||||
<p>Tests can be grouped into suites, using the <code>SUITE</code> macro. A suite serves as a namespace for test names, so that the same test name can be used in two difference contexts.</p>
|
||||
|
||||
<pre>
|
||||
SUITE(YourSuiteName)
|
||||
{
|
||||
TEST(YourTestName)
|
||||
{
|
||||
}
|
||||
|
||||
TEST(YourOtherTestName)
|
||||
{
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>This will place the tests into a C++ namespace called <code>YourSuiteName</code>, and make the suite name available to UnitTest++. <code>RunAllTests()</code> can be called for a specific suite name, so you can use this to build named groups of tests to be run together.</p>
|
||||
|
||||
<h3>Simple check macros</h3>
|
||||
<p>In test cases, we want to check the results of our system under test. UnitTest++ provides a number of check macros that handle comparison and proper failure reporting.</p>
|
||||
|
||||
<p>The most basic variety is the boolean <code>CHECK</code> macro:</p>
|
||||
|
||||
<pre>
|
||||
CHECK(false); // fails
|
||||
</pre>
|
||||
|
||||
<p>It will fail if the boolean expression evaluates to false.</p>
|
||||
|
||||
<p>For equality checks, it's generally better to use <code>CHECK_EQUAL</code>:</p>
|
||||
|
||||
<pre>
|
||||
CHECK_EQUAL(10, 20); // fails
|
||||
CHECK_EQUAL("foo", "bar"); // fails
|
||||
</pre>
|
||||
|
||||
<p>Note how <code>CHECK_EQUAL</code> is overloaded for C strings, so you don't have to resort to <code>strcmp</code> or similar. There is no facility for case-insensitive comparison or string searches, so you may have to drop down to a plain boolean <code>CHECK</code> with help from the CRT:</p>
|
||||
|
||||
<pre>
|
||||
CHECK(std::strstr("zaza", "az") != 0); // succeeds
|
||||
</pre>
|
||||
|
||||
<p>For floating-point comparison, equality <a href="http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm">isn't necessarily well-defined</a>, so you should prefer the <code>CHECK_CLOSE</code> macro:</p>
|
||||
|
||||
<pre>
|
||||
CHECK_CLOSE(3.14, 3.1415, 0.01); // succeeds
|
||||
</pre>
|
||||
|
||||
<p>All of the macros are tailored to avoid unintended side-effects, for example:</p>
|
||||
|
||||
<pre>
|
||||
TEST(CheckMacrosHaveNoSideEffects)
|
||||
{
|
||||
int i = 4;
|
||||
CHECK_EQUAL(5, ++i); // succeeds
|
||||
CHECK_EQUAL(5, i); // succeeds
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>The check macros guarantee that the <code>++i</code> expression isn't repeated internally, as demonstrated above.</p>
|
||||
|
||||
<h3>Array check macros</h3>
|
||||
<p>There is a set of check macros for array comparison as well:</p>
|
||||
|
||||
<pre>
|
||||
const float oned[2] = { 10, 20 };
|
||||
CHECK_ARRAY_EQUAL(oned, oned, 2); // succeeds
|
||||
CHECK_ARRAY_CLOSE(oned, oned, 2, 0.00); // succeeds
|
||||
|
||||
const float twod[2][3] = { {0, 1, 2}, {2, 3, 4} };
|
||||
CHECK_ARRAY2D_CLOSE(twod, twod, 2, 3, 0.00); // succeeds
|
||||
</pre>
|
||||
|
||||
<p>The array equal macro compares elements using <code>operator==</code>, so <code>CHECK_ARRAY_EQUAL</code> won't work for an array of C strings, for example.</p>
|
||||
|
||||
<p>The array close macros are similar to the regular CHECK_CLOSE macro, and are really only useful for scalar types, that can be compared in terms of a difference between two array elements.</p>
|
||||
|
||||
<p>Note that the one-dimensional array macros work for <code>std::vector</code> as well, as it can be indexed just as a C array.</p>
|
||||
|
||||
<h3>Exception check macros</h3>
|
||||
<p>Finally, there's a <code>CHECK_THROW</code> macro, which asserts that its enclosed expression throws the specified type:</p>
|
||||
|
||||
<pre>
|
||||
struct TestException {};
|
||||
CHECK_THROW(throw TestException(), TestException); // succeeds
|
||||
</pre>
|
||||
|
||||
<p>UnitTest++ natively catches exceptions if your test code doesn't. So if your code under test throws any exception UnitTest++ will fail the test and report either using the <code>what()</code> method for <code>std::exception</code> derivatives or just a plain message for unknown exception types.</p>
|
||||
|
||||
<p>Should your test or code raise an irrecoverable error (an Access Violation on Win32, for example, or a signal on Linux), UnitTest++ will attempt to map them to an exception and fail the test, just as for other unhandled exceptions.</p>
|
||||
|
||||
<h3>Time constraints</h3>
|
||||
<p>UnitTest++ can fail a test if it takes too long to complete, using so-called time constraints.</p>
|
||||
|
||||
<p>They come in two flavors; <em>local</em> and <em>global</em> time constraints.</p>
|
||||
|
||||
<p>Local time constraints are limited to the current scope, like so:</p>
|
||||
|
||||
<pre>
|
||||
TEST(YourTimedTest)
|
||||
{
|
||||
// Lengthy setup...
|
||||
|
||||
{
|
||||
UNITTEST_TIME_CONSTRAINT(50);
|
||||
|
||||
// Do time-critical stuff
|
||||
}
|
||||
|
||||
// Lengthy teardown...
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>The test will fail if the "Do time-critical stuff" block takes longer than 50 ms to complete. The time-consuming setup and teardown are not measured, since the time constraint is scope-bound. It's perfectly valid to have multiple local time constraints in the same test, as long as there is only one per block.</p>
|
||||
|
||||
<p>A global time constraint, on the other hand, requires that all of the tests in a test run are faster than a specified amount of time. This allows you, when you run a suite of tests, to ask UnitTest++ to fail it entirely if any test exceeds the global constraint. The max time is passed as a parameter to an overload of <code>RunAllTests()</code>.</p>
|
||||
|
||||
<p>If you want to use a global time constraint, but have one test that is notoriously slow, you can exempt it from inspection by using the <code>UNITTEST_TIME_CONSTRAINT_EXEMPT</code> macro anywhere inside the test body.</p>
|
||||
|
||||
<pre>
|
||||
TEST(NotoriouslySlowTest)
|
||||
{
|
||||
UNITTEST_TIME_CONSTRAINT_EXEMPT();
|
||||
|
||||
// Oh boy, this is going to take a while
|
||||
...
|
||||
}
|
||||
</pre>
|
||||
|
||||
<h3>Test runners</h3>
|
||||
<p>The <code>RunAllTests()</code> function has an overload that lets you customize the behavior of the runner, such as global time constraints, custom reporters, which suite to run, etc.</p>
|
||||
|
||||
<pre>
|
||||
int RunAllTests(TestReporter& reporter, TestList const& list, char const* suiteName, int const maxTestTimeInMs);
|
||||
</pre>
|
||||
|
||||
<p>If you attempt to pass custom parameters to <code>RunAllTests()</code>, note that the <code>list</code> parameter should have the value <code>Test::GetTestList()</code>.</p>
|
||||
|
||||
<p>The parameterless <code>RunAllTests()</code> is a simple wrapper for this one, with sensible defaults.</p>
|
||||
|
||||
<h3>Example setup</h3>
|
||||
<p>How to create a new test project varies depending on your environment, but here are some directions on common file structure and usage.</p>
|
||||
|
||||
<p>The general idea is that you keep one <code>Main.cpp</code> file with the entry-point which calls <code>RunAllTests()</code>.</p>
|
||||
|
||||
<p>Then you can simply compile and link new .cpp files at will, typically one per test suite.</p>
|
||||
|
||||
<pre>
|
||||
+ ShaverTests/
|
||||
|
|
||||
+- Main.cpp
|
||||
|
|
||||
+- TestBrush.cpp
|
||||
+- TestEngine.cpp
|
||||
+- TestRazor.cpp
|
||||
</pre>
|
||||
|
||||
<p>Each of the <code>Test*.cpp</code> files will contain one or more <code>TEST</code> macro incantations with the associated test code. There are no source-level dependencies between <code>Main.cpp</code> and <code>Test*.cpp</code>, as the <code>TEST</code> macro handles the registration and setup necessary for <code>RunAllTests()</code> to find all tests compiled into the same final executable.</p>
|
||||
|
||||
<p>UnitTest++ does not require this structure, even if this is how the library itself does it. As long as your test project contains one or more <code>TESTs</code> and calls <code>RunAllTests()</code> at one point or another, it will be handled by UnitTest++.</p>
|
||||
|
||||
<p>It's common to make the generated executable start as a post-build step, so that merely building your test project will run the tests as well. Since the exit code is the count of failures, a failed test will generally break the build, as most build engines will fail a build if any step returns a non-zero exit code.</p>
|
||||
|
||||
</body>
|
||||
</html>
|
||||
230
unittest-cpp.spec
Normal file
230
unittest-cpp.spec
Normal file
|
|
@ -0,0 +1,230 @@
|
|||
%global _hardened_build 1
|
||||
%global oldname UnitTest++
|
||||
|
||||
Name: unittest-cpp
|
||||
Version: 2.0.0
|
||||
Release: 23%{?dist}
|
||||
Summary: Lightweight unit testing framework for C++
|
||||
License: MIT
|
||||
|
||||
URL: https://github.com/%{name}/%{name}
|
||||
Source0: %url/archive/v%{version}/%{name}-%{version}.tar.gz
|
||||
# documentation from 1.4 tarball: docs/UnitTest++.html
|
||||
Source1: %{name}.html
|
||||
# Fix configure.ac version test
|
||||
Patch0: fix_version_2.0.0.patch
|
||||
|
||||
BuildRequires: make
|
||||
BuildRequires: gcc-c++
|
||||
BuildRequires: autoconf
|
||||
BuildRequires: libtool
|
||||
|
||||
%description
|
||||
%{name} is a lightweight unit testing framework for C++.
|
||||
Simplicity, portability, speed, and small footprint are all
|
||||
very important aspects of %{name}.
|
||||
|
||||
%package devel
|
||||
Summary: Object files for development using %{name}
|
||||
Requires: %{name}%{?_isa} = %{version}-%{release}
|
||||
|
||||
%description devel
|
||||
The %{name}-devel package contains the object files
|
||||
necessary for developing test programs.
|
||||
|
||||
%package static
|
||||
Summary: Static library for %{name}
|
||||
Requires: %{name}%{?_isa} = %{version}-%{release}
|
||||
|
||||
%description static
|
||||
The %{name}-static package contains the object files
|
||||
necessary for statically linking test programs.
|
||||
|
||||
%prep
|
||||
%autosetup -p1
|
||||
cp -p %SOURCE1 .
|
||||
# autoreconf will complain about missing NEWS and README files
|
||||
touch NEWS
|
||||
ln README.md README
|
||||
# autoreconf will add a GPLv3 license text in COPYING
|
||||
ln LICENSE COPYING
|
||||
autoreconf -i
|
||||
|
||||
%build
|
||||
%configure
|
||||
# rpmlint unused-direct-shlib-dependency
|
||||
sed -i -e 's! -shared ! -Wl,--as-needed\0!g' libtool
|
||||
%make_build
|
||||
|
||||
%check
|
||||
make check
|
||||
|
||||
%install
|
||||
%make_install
|
||||
rm -f %{buildroot}%{_libdir}/lib%{oldname}.la
|
||||
|
||||
%files
|
||||
%doc AUTHORS README.md
|
||||
%license LICENSE
|
||||
%{_libdir}/lib%{oldname}.so.2*
|
||||
|
||||
%files devel
|
||||
%doc %{name}.html
|
||||
%{_includedir}/%{oldname}
|
||||
%{_libdir}/lib%{oldname}.so
|
||||
%{_libdir}/pkgconfig/UnitTest++.pc
|
||||
|
||||
%files static
|
||||
%{_libdir}/lib%{oldname}.a
|
||||
|
||||
%ldconfig_scriptlets
|
||||
|
||||
%changelog
|
||||
* Fri Jul 17 2026 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-23
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_45_Mass_Rebuild
|
||||
|
||||
* Sat Jan 17 2026 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-22
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_44_Mass_Rebuild
|
||||
|
||||
* Fri Jul 25 2025 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-21
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_43_Mass_Rebuild
|
||||
|
||||
* Sun Jan 19 2025 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-20
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_42_Mass_Rebuild
|
||||
|
||||
* Sat Jul 20 2024 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-19
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_41_Mass_Rebuild
|
||||
|
||||
* Sat Jan 27 2024 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-18
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
|
||||
|
||||
* Sat Jul 22 2023 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-17
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
|
||||
|
||||
* Sat Jan 21 2023 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-16
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
|
||||
|
||||
* Sat Jul 23 2022 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-15
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
|
||||
|
||||
* Sat Jan 22 2022 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-14
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
|
||||
|
||||
* Fri Jul 23 2021 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-13
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
|
||||
|
||||
* Wed Jan 27 2021 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-12
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
|
||||
|
||||
* Sat Aug 01 2020 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-11
|
||||
- Second attempt - Rebuilt for
|
||||
https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
|
||||
|
||||
* Wed Jul 29 2020 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-10
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
|
||||
|
||||
* Fri Feb 14 2020 Leigh Scott <leigh123linux@gmail.com> - 2.0.0-9
|
||||
- Update to 2.0.0 release
|
||||
|
||||
* Fri Jan 31 2020 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-8
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
|
||||
|
||||
* Sat Jul 27 2019 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-7
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
|
||||
|
||||
* Sun Feb 03 2019 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-6
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
|
||||
|
||||
* Sat Jul 14 2018 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-5
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
|
||||
|
||||
* Fri Feb 09 2018 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-4
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
|
||||
|
||||
* Thu Aug 03 2017 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-3
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
|
||||
|
||||
* Thu Jul 27 2017 Fedora Release Engineering <releng@fedoraproject.org> - 2.0.0-2
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
|
||||
|
||||
* Sat Jun 10 2017 Raphael Groner <projects.rg@smart.ms> - 2.0.0-1
|
||||
- new version
|
||||
|
||||
* Sat Feb 11 2017 Fedora Release Engineering <releng@fedoraproject.org> - 1.6.1-2
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
|
||||
|
||||
* Tue Jun 07 2016 Raphael Groner <projects.rg@smart.ms> - 1.6.1-1
|
||||
- bump to v1.6.1, rhbz#1333400
|
||||
|
||||
* Mon Mar 28 2016 François Cami <fcami@fedoraproject.org> - 1.6.0-1.20160301gitb69b63a
|
||||
- Update to 1.6.0 + drop our .pc file (ship upstream's instead).
|
||||
|
||||
* Fri Feb 05 2016 Fedora Release Engineering <releng@fedoraproject.org> - 1.4-19.20130823gite76d25a
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild
|
||||
|
||||
* Fri Jun 19 2015 Fedora Release Engineering <rel-eng@lists.fedoraproject.org> - 1.4-18.20130823gite76d25a
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild
|
||||
|
||||
* Sat May 02 2015 Kalev Lember <kalevlember@gmail.com> - 1.4-17.20130823gite76d25a
|
||||
- Rebuilt for GCC 5 C++11 ABI change
|
||||
|
||||
* Mon Aug 18 2014 Fedora Release Engineering <rel-eng@lists.fedoraproject.org> - 1.4-16.20130823gite76d25a
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild
|
||||
|
||||
* Sun Jun 08 2014 Fedora Release Engineering <rel-eng@lists.fedoraproject.org> - 1.4-15.20130823gite76d25a
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
|
||||
|
||||
* Fri Nov 22 2013 Luke Benstead <kazade@fedoraproject.org> - 1.4-14.20130823gite76d25a
|
||||
- Fix .spec file after previous change
|
||||
|
||||
* Fri Nov 22 2013 Luke Benstead <kazade@fedoraproject.org> - 1.4-13.20130823gite76d25a
|
||||
- Rename the .pc file to be consistent with other platforms
|
||||
|
||||
* Fri Nov 22 2013 François Cami <fcami@fedoraproject.org> - 1.4-12.20130823gite76d25a
|
||||
- Misc. spec fixes.
|
||||
|
||||
* Thu Nov 21 2013 Luke Benstead <kazade@fedoraproject.org> - 1.4-11.20130823gite76d25a
|
||||
- Bump to latest upstream.
|
||||
|
||||
* Sun Aug 04 2013 Fedora Release Engineering <rel-eng@lists.fedoraproject.org> - 1.4-11.20130509gitc42e68b
|
||||
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
|
||||
|
||||
* Thu Jun 06 2013 François Cami <fcami@fedoraproject.org> - 1.4-10.20130509gitc42e68b
|
||||
- Make -static depend on -devel. Suggested by Michael Schwendt.
|
||||
|
||||
* Fri May 31 2013 François Cami <fcami@fedoraproject.org> - 1.4-9.20130509gitc42e68b
|
||||
- Use github directly for git tarball generation.
|
||||
- Move autoreconf to %%build.
|
||||
- Add %%check.
|
||||
- Removed duplicate files.
|
||||
- All changes suggested by Björn Esser.
|
||||
|
||||
* Thu May 30 2013 François Cami <fcami@fedoraproject.org> - 1.4-8.20130509gitc42e68bb
|
||||
- Switch upstream from http://sf.net/projects/unittest-cpp
|
||||
to https://github.com/unittest-cpp/unittest-cpp
|
||||
- Rebase sources to c42e68bb999d01da9ec71b67ff1a2cbd6ec1b6a6
|
||||
- Use consistent naming as much as possible.
|
||||
- Use autotools to build both shared and static libraries.
|
||||
- Most changes suggested by Michael Schwendt.
|
||||
|
||||
* Wed Mar 13 2013 François Cami <fcami@fedoraproject.org> - 1.4-7
|
||||
- Fix linker flags breakage.
|
||||
|
||||
* Tue Mar 12 2013 François Cami <fcami@fedoraproject.org> - 1.4-6
|
||||
- Replace %%define with %%global.
|
||||
|
||||
* Wed Mar 6 2013 François Cami <fcami@fedoraproject.org> - 1.4-5
|
||||
- Remove unneeded space in sed expression.
|
||||
|
||||
* Wed Mar 6 2013 François Cami <fcami@fedoraproject.org> - 1.4-4
|
||||
- Use consistent naming in .pc file (fix by Luke Benstead).
|
||||
|
||||
* Wed Feb 27 2013 François Cami <fcami@fedoraproject.org> - 1.4-3
|
||||
- Use multi-line, single-instance sed, courtesy of Dennis Johnson.
|
||||
|
||||
* Sat Feb 23 2013 François Cami <fcami@fedoraproject.org> - 1.4-2
|
||||
- Change package name. Add .pc file courtesy of Luke Benstead.
|
||||
|
||||
* Sat Feb 02 2013 François Cami <fcami@fedoraproject.org> - 1.4-1
|
||||
- Initial Fedora RPM.
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue