View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0015234CMakeCMakepublic2014-11-04 23:152016-06-10 14:31
ReporterLAN Xingcan 
Assigned ToKitware Robot 
PlatformAnyOSAnyOS VersionAny
Product VersionCMake 3.0 
Target VersionFixed in Version 
Summary0015234: [Feature Request] Allow interface library have public header source
DescriptionBy allowing this. The public header installation needn't to be manually specified by INSTALL(FILES ...). And this make it more friendly for IDE to cooperating with CMake.
Attached Files


patrik (reporter)
2015-07-01 18:45
edited on: 2015-07-01 18:46

In my opinion, this is quite a big issue. It's hard and requires ugly hacks to get a header-only library show up as a target in an IDE (e.g. Visual Studio) with its header files. It would be great if we could just specify the files and make the target show up in VS, like

add_library(mylib INTERFACE h1.hpp h2.hpp)

The target_sources command is not a viable option either.

This is quite a hot topic, e.g.: [^] [^]

LAN Xingcan (reporter)
2015-07-09 14:39

Brad King (manager)
2015-07-09 14:45

INTERFACE targets were designed to propagate usage requirements without having any actual build rules associated with the target itself. This issue is purely about IDE behavior for such targets. The IDE generators could perhaps be taught to add INTERFACE targets as project files but not have any actual build rules in them.
patrik (reporter)
2015-07-09 14:52

>> The IDE generators could perhaps be taught to add INTERFACE targets as project files

But how is the IDE generator supposed to know which files? As it is now, it's not possible to specify which header files belong to the target.

I guess what we want is the following: To specify a target with no build rules (header-only) but associate files with it (headers), and these files should show up in the IDE. These targets should also be possible to specify as dependencies in other targets, to, for example, propagate an include directory.

Basically, make header-only targets first class citizens in CMake instead of requiring unsatisfactory hacks with no semantic information.
Brad King (manager)
2015-07-09 16:01

Design discussion like this is better held on the developer's mailing list: [^]

where it can reach a broader audience.
Brad King (manager)
2015-07-10 09:50

Thanks for starting the thread. For reference, it is here:

 Header-only library targets [^]
Jan Rüegg (reporter)
2015-10-26 10:26

Any update on this?

I agree with the comment here: [^]

in that it would be great to lift this restriction for sources that do
not compile (but make it an error to add a compiling source).

Can this be implemented or is there anything more that needs to be discussed?
Brad King (manager)
2015-10-26 10:36

Re 0015234:0039676: Please respond to that message on-list with a proposal to implement a specific interface discussed there.
Kitware Robot (administrator)
2016-06-10 14:29

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2014-11-04 23:15 LAN Xingcan New Issue
2015-07-01 18:45 patrik Note Added: 0039011
2015-07-01 18:46 patrik Note Edited: 0039011
2015-07-09 14:39 LAN Xingcan Note Added: 0039112
2015-07-09 14:39 LAN Xingcan Tag Attached: CMake
2015-07-09 14:45 Brad King Note Added: 0039114
2015-07-09 14:52 patrik Note Added: 0039116
2015-07-09 16:01 Brad King Note Added: 0039117
2015-07-10 09:50 Brad King Note Added: 0039123
2015-10-26 10:26 Jan Rüegg Note Added: 0039676
2015-10-26 10:36 Brad King Note Added: 0039677
2016-06-10 14:29 Kitware Robot Note Added: 0042658
2016-06-10 14:29 Kitware Robot Status new => resolved
2016-06-10 14:29 Kitware Robot Resolution open => moved
2016-06-10 14:29 Kitware Robot Assigned To => Kitware Robot
2016-06-10 14:31 Kitware Robot Status resolved => closed

Copyright © 2000 - 2018 MantisBT Team