# Header only library
%global debug_package %{nil}

# Use clang so that the fuzzers can be built and used as a test until Catch2 v3
# is packaged to Fedora. The fuzzers use a unique fuzzing feature of clang which
# is not present in GCC.
%global toolchain clang

# The clang fuzzer is not available on ppc64le.
%ifarch ppc64le
%global build_fuzzers 0
%else
%global build_fuzzers 1
%endif

%global forgeurl https://github.com/maxbachmann/rapidfuzz-cpp
Version: 1.10.4
%forgemeta

Name: rapidfuzz-cpp
Release: %{autorelease}
License: MIT
Summary: A fast string matching header-only library for C++
URL: %{forgeurl}
Source: %{forgesource}
# Upstream PR: https://github.com/maxbachmann/rapidfuzz-cpp/pull/99
Patch0: rapidfuzz-cpp-1.10.4-overflow.patch

BuildRequires: cmake
BuildRequires: doxygen
BuildRequires: clang
%if %build_fuzzers
BuildRequires: compiler-rt
%endif
# For tests once Catch2 v3 lands in Fedora
# https://bugzilla.redhat.com/show_bug.cgi?id=1786881
#BuildRequires: catch-static

%global _description %{expand:
RapidFuzz is a fast string matching library for Python and C++, which is using
the string similarity calculations from FuzzyWuzzy. However there are two
aspects that set RapidFuzz apart from FuzzyWuzzy:

1. It is MIT licensed so it can be used whichever License you might want to
   choose for your project, while you're forced to adopt the GPL license when
   using FuzzyWuzzy

2. It is mostly written in C++ and on top of this comes with a lot of
   Algorithmic improvements to make string matching even faster, while still
   providing the same results.

This is the C++ component of RapidFuzz, the Python library is available in the
python-rapidfuzz package.}

%description %_description

%package devel
Summary: Development files for the RapidFuzz C++ library
Provides: %{name}-static = %{version}

%description devel
%_description

%prep
%autosetup -p1
# Change the group name, mainly so that the manpage is named meaningfully
sed -i 's/defgroup Fuzz Fuzz/defgroup rapidfuzz rapidfuzz/' rapidfuzz/fuzz.hpp
# Enable man generation, but don't enable the links since it produces files
# which aren't named specifically for rapidfuzz, such as "ratio" and
# "partial_ratio".
echo "GENERATE_MAN           = YES" >> Doxyfile
# There doesn't seem to be a reasonable way to comply with bundling guidelines
# where there is arbitrary jquery and similar bundled in the HTML generated by
# doxygen, so don't use it.
echo "GENERATE_HTML          = NO" >> Doxyfile

%build
# Testing needs v3 of Catch2
# %%cmake -DRAPIDFUZZ_BUILD_TESTING=ON
# Use the fuzzers as a test of the code build & execution
%if %build_fuzzers
%cmake -DRAPIDFUZZ_BUILD_FUZZERS=ON
%else
%cmake
%endif
%cmake_build
# Build the doxygen man doc
doxygen

%install
%cmake_install
mkdir -p %{buildroot}%{_mandir}/man3/
# Only install rapidfuzz.3, which is named specifically for this package, and
# not the generic "citelist.3".
cp doxygen/man/man3/rapidfuzz.3 %{buildroot}/%{_mandir}/man3/

%if %build_fuzzers
%check
# Unittests need v3 of Catch2
# %%ctest
# Use the fuzzers as a test of the build & execution
cd "%{__cmake_builddir}"
for fuzz_exe in fuzzing/fuzz_*
do
    # True fuzz testing would have some known corpus and probably lots more
    # runs, but here this is used as a simple "smoketest" to confirm things
    # build and run OK from the library, so limit the runs to something
    # reasonable.
    ./$fuzz_exe -runs=1000 -max_len=256
done
%endif

%files devel
%license LICENSE
%doc README.md CHANGELOG.md
%{_mandir}/man3/rapidfuzz.3*
%{_includedir}/rapidfuzz
%{_libdir}/cmake/rapidfuzz

%changelog
%autochangelog