Bug 2217275 - doctest CMake integration doesn't use /usr/include/doctest location
Summary: doctest CMake integration doesn't use /usr/include/doctest location
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: doctest
Version: 43
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Nick Black
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-06-25 21:08 UTC by Georg Sauthoff
Modified: 2025-11-30 12:29 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2024-11-27 21:13:49 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Georg Sauthoff 2023-06-25 21:08:51 UTC
The doctest documentation on cmake includes a minimal example that fails to compile on Fedora 37, when doctest-devel is installed:

https://github.com/doctest/doctest/blob/master/doc/markdown/build-systems.md#cmake


```
add_executable(tests main.cpp)
target_compile_features(tests PRIVATE cxx_std_17)
target_link_libraries(tests PRIVATE doctest::doctest)
```

Reproducible: Always

Steps to Reproduce:
1. dnf install doctest-devel
2. create CMakeLists.txt, check.cc check_main.cc such that:
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 3.7...3.26)
project(foo CXX)
find_package(doctest REQUIRED)
add_executable(check check_main.cc check.cc)
target_link_libraries(check PRIVATE doctest::doctest)
$ cat check_main.cc
cat check_main.cc 
#define DOCTEST_CONFIG_IMPLEMENT_WITH_MAIN
#include <doctest.h>
$ cat check.cc
#include <doctest.h>
TEST_CASE("dummy test")
{
    CHECK(23 == 46/2);
}
3. mkdir build
4. cd build
5. cmake ..
6. make check
Actual Results:  
/home/juser/doctest-foo/check_main.cc:2:10: fatal error: doctest.h: No such file or directory
    2 | #include <doctest.h>
      |          ^~~~~~~~~~~
compilation terminated

Expected Results:  
No compile errors and succeeding test.

Since the doctest-devel package installs the doctest header into /usr/include/doctest, the expectation here is that INCLUDE_DIRECTORIES property is updated accordingly when target linking doctest::doctest in CMakeLists.txt.

The package also contains /usr/lib64/cmake/doctest/doctestTargets.cmake contains code for this, but apparently it doesn't work for the Fedora specific install location.

This change fixes the issue for me:

```
--- doctestTargets.cmake	2023-06-25 22:44:46.100690490 +0200
+++ /usr/lib64/cmake/doctest/doctestTargets.cmake	2023-06-25 22:45:00.974747944 +0200
@@ -64,7 +64,7 @@
 
 set_target_properties(doctest::doctest PROPERTIES
   INTERFACE_COMPILE_FEATURES "cxx_std_11"
-  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
+  INTERFACE_INCLUDE_DIRECTORIES "/usr/include/doctest"
 )
 
 if(CMAKE_VERSION VERSION_LESS 3.0.0)
```

Of course, one can also work around it my manually adding /usr/include/doctest to the test executable cmake target, but that would be a quite Fedora specific workaround.

I think it's appropriate for the Fedora doctest-devel to include the above patch (or a similar one) - or simply to move the doctest.h header to /usr/include.

Comment 1 Aoife Moloney 2023-11-23 01:47:18 UTC
This message is a reminder that Fedora Linux 37 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '37'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 37 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 2 Aoife Moloney 2024-11-08 10:54:17 UTC
This message is a reminder that Fedora Linux 39 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '39'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 39 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 3 Aoife Moloney 2024-11-27 21:13:49 UTC
Fedora Linux 39 entered end-of-life (EOL) status on 2024-11-26.

Fedora Linux 39 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 4 Nick Black 2025-11-18 07:44:22 UTC
it seems to me that this patch ought go upstream, no?

Comment 5 Georg Sauthoff 2025-11-30 12:29:39 UTC
(In reply to Nick Black from comment #4)
> it seems to me that this patch ought go upstream, no?

It depends.

Maybe upstream expects `doctest.h` to be installed under `$PREFIX/include` i.e. `/usr/include`,
and downstream decided to deviate from that default and install the header under /usr/include/doctest, instead.
In that case one could argue that downstream has the responsibility to also adjust doctest's cmake integration.

Or perhaps doctest upstream actually wants to support /usr/include/doctest as target,
but then it must change its cmake integration and/or its example.

Of course, it's also an option to approach upstream and request out-of-the-box support for installing to /usr/include/docstream, in case it doesn't already exist.


Note You need to log in before you can comment on or make changes to this bug.