CMake not finding headers from library in subproject

Question

Update: Fixed I've corrected the CMakeLists.txt file below: I had left out a slash. So the solution was adding ${CMAKE_CURRENT_LIST_DIR} to the path for target_include_directories.

I'm trying to use libharu as a subproject. I've set it up as a git submodule in my project in the libharu directory and made edits to the CMakeLists.txt file (changing CMAKE_*_DIR references to PROJECT_*_DIR so it will behave as a subproject as per an unresolved issue raised on the library).

In my main CMakeLists.txt file I have (edited per suggestions in comments and answers)

add_subdirectory(libharu)

add_executable ( gftopdf)

target_link_libraries(gftopdf libharu)

target_sources(gftopdf PRIVATE
        main.cpp
        Bitmap.cpp
        GFReader.cpp
        PDFWriter.cpp
        )

target_include_directories(gftopdf PRIVATE ${CMAKE_CURRENT_LIST_DIR}/libharu/include)

(I've also tried without the include on the target_include_directories) but when I try to do

#include "hpdf.h"

I get an error 'hpdf.h' file not found. I'm assuming this is something really basic, but I'm new to CMake.

I did see that I have this warning which is probably relevant:

CMake Warning (dev):
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  MACOSX_RPATH is not specified for the following targets:

   hpdf

(CLion is inconsistent about showing me the CMake run output when I make changes so I hadn't noticed this before.) Adding

set(CMAKE_MACOSX_RPATH 0)

(or 1) removes the warning but does not resolve the issue, so I suspect it's unrelated.

`add_executable` should be above `target_include_directories`. Also this `add_subdirectory(libharu)` is disturbing. — Marek R, Mar 26 '21 at 15:31
"my code says that hpdf.h can't be found." - Please, provide (add to the question post) the **exact error message**, which includes the information about the files involved. — Tsyvarev, Mar 26 '21 at 15:37
@Tsyvarev The **exact error message** is `'hpdf.h' file not found`. — Don Hosek, Mar 26 '21 at 15:41
@DonHosek since at the same time you add this directory as `target_include_directories(gftodvi PRIVATE libharu/include)`. If you do `add_subdirectory(libharu)` you should not reach this directory by other ways (everything needed fr that directory should be done there). — Marek R, Mar 26 '21 at 15:44
@MarekR It's entirely possible that the `libharu` `CMakeLists.txt` is improperly configured. So, assuming that it were correctly set up, I would only need the `add_subdirectory` and `target_link_libraries` directives? — Don Hosek, Mar 26 '21 at 15:50
[possible duplicate](https://stackoverflow.com/a/51567322/1387438), but not sure if it relay is dupe (if I mark this as duplicate question will be closed immediately so will not do it). — Marek R, Mar 26 '21 at 15:51
So, have you used `CMAKE_CURRENT_LIST_DIR` in the **original** code, which suffers from the error? As currently written, `${CMAKE_CURRENT_LIST_DIR}libharu/include` misses a slash (``/``) between the variable's dereference and `libharu`. — Tsyvarev, Mar 26 '21 at 16:05
On Stack Overflow we do NOT mess a **question post** with a **solution**. That is, a question post should always contain a correct problem statement, even after the problem is resolved. If you feel that the manner of the solution won't help to other users, then simply delete the question. (Actually, your question fits for the category 2 of close reasons, listed at https://stackoverflow.com/help/on-topic). — Tsyvarev, Mar 26 '21 at 16:25

score 0 · Accepted Answer · 2021-03-26T15:47:05.087

0

I fixed up the code real quick based on my guesses.

add_executable(gftodvi)

# This part is probably fine
add_subdirectory(libharu)

target_link_libraries(gftodvi PRIVATE libharu)

# This line is the probably the cause of your problems
# If libharu was written using modern cmake this wouldn't have been an issue.
# Because they would have made the appropriate include directories PUBLIC
target_include_directories(gftodvi PRIVATE 
    ${CMAKE_CURRENT_LIST_DIR}/libharu/include
)

# Prefer target sources in newer cmake
target_sources(gftodvi PRIVATE 
    main.cpp 
    Bitmap.cpp  
    GFReader.cpp 
    PDFWriter.cpp
)

Sorry for the quick edits I believe the above code should work now.

Essentially I believe the problem is gftodvi isn't getting the appropriate include directories. libharu uses CMake 2.X so you need to specify the include directories yourself manually.

edited Mar 26 '21 at 15:47

answered Mar 26 '21 at 15:40

1

Unless you use some very old CMake, [target_include_directories](https://cmake.org/cmake/help/v3.20/command/target_include_directories.html) correctly processes **relative** paths. So your original `target_include_directories(gftodvi PRIVATE libharu/include)` should work too. Which CMake version you actually use? And what is `cmake_minimum_requires` line in **your** `CMakeLists.txt`? – Tsyvarev Mar 26 '21 at 15:54
Are you asking me? I use 3.20. I just guessed the person asking was using something real old when I looked at libharu – Mar 27 '21 at 00:09
Oops, sorry, I thought this is an answer provided by the asker. Anyway, the question remains: How exactly your answer **resolves the problem** stated in the question post (`'hpdf.h' file not found`)? Does it resolves the problem by replacing the *relative* path with the *absolute* one? As the asker got warning for policy [CMP0042](https://cmake.org/cmake/help/latest/policy/CMP0042.html), it uses at least CMake 3.0. [Documentation](https://cmake.org/cmake/help/v3.0/command/target_include_directories.html) for that version notes that `target_include_directories` accepts relative paths too. – Tsyvarev Mar 27 '21 at 10:08
Well it's been a while but I remember there were other issues in their code. I agree the absolute path for target_include_directories probably wasn't the cause. I remember I fixed something else. – Mar 27 '21 at 16:31

CMake not finding headers from library in subproject

1 Answers1