cmake and GenerateExportHeader

Question

I'm trying to use GenerateExportHeader module from cmake.

part of my CmakeLists.txt:

add_compiler_export_flags()
add_library(gui SHARED ${gui_CPP} ${gui_HPP})
generate_export_header(gui)

it works nice for gui project itself, but when I try to include gui's .h files in another project, an #include "gui_export.h" cannot be find. This is obvious as gui_export.h was created in gui's build dir which is not in include path of other projects.

The simple solution would be to add gui's build dir to other project's includes but: 1. I don't find it as a kosher solution 2. I could not actually even find how to find out what is the build dir of a target

how can I solve this problem well?

hm, are you trying to not target-link two projects/dlls but still use header declarations of your gui files over in different projects? — Najzero, Jun 07 '13 at 11:04

score 11 · Answer 1 · answered Jun 20 '13 at 07:52

11

I've solved this problem by using EXPORT_FILE_NAME, so now I have:

generate_export_header(gui EXPORT_FILE_NAME ${CMAKE_BINARY_DIR}/exports/gui_export.h)

and in all projects I add ${CMAKE_BINARY_DIR}/exports/ to includes

answered Jun 20 '13 at 07:52

Michał Walenciak

4,257
4
33
61

score 9 · Accepted Answer · answered Jan 12 '15 at 17:43

With modern (i.e. 2.8.11 or later) CMake, the preferred mechanism is:

target_include_directories(gui PUBLIC ${CMAKE_BINARY_DIR}/exports)

Then when you export() your library (which you should do!) or otherwise use it in a context where the target interface properties are known (e.g. in the same overall CMake project, which seems to be what you are doing), target_link_libraries(foo gui) will also pick up the necessary include directory.

Putting it in a well known directory is somewhat orthogonal. In either case, it is recommended to use target_include_directories to tell consumers where to find your library's headers.

user2488920 · Answer 3 · 2013-06-15T13:29:59.313

-3

Use export() to allow CMake to find your build tree. You can take a look at openobex on gitorious to see how the config.cmake file has to look like.

OTOH, you should not use that generated export header in your public header or install it.

edited Jun 15 '13 at 13:29

answered Jun 15 '13 at 13:23

user2488920

1
1

1

Your advice about not publishing header with exports sounds interesting but I don't catch the idea. Let imagine I have a library with a single cpp file with a class A. When i build under windows I need to tell this class to be exported. As far as I know it is usually done by preparing .h file with definition of class A with __declspec(dllexport). From the other side, when i want to use this class somewhere else, I should use __declspec(dllimport). This is what generate_export_header does. How then it should be done without publishing this export file? – Michał Walenciak Jun 18 '13 at 08:19
1

That makes no sense. Export headers are *meant* to be used by consumers of the library as well as the library itself. – Matthew Jan 12 '15 at 17:41
3

The header has to be exported. Their is no way around it. In your install target, you copy it out and it is included in with your other headers. – Atif Jun 02 '16 at 18:08

cmake and GenerateExportHeader

3 Answers3

Linked