MantisBT - CMake
View Issue Details
0015234CMakeCMakepublic2014-11-04 23:152016-06-10 14:31
LAN Xingcan 
Kitware Robot 
normalminoralways
closedmoved 
AnyAnyAny
CMake 3.0 
 
0015234: [Feature Request] Allow interface library have public header source
By 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.
CMake
Issue History
2014-11-04 23:15LAN XingcanNew Issue
2015-07-01 18:45patrikNote Added: 0039011
2015-07-01 18:46patrikNote Edited: 0039011bug_revision_view_page.php?bugnote_id=39011#r1816
2015-07-09 14:39LAN XingcanNote Added: 0039112
2015-07-09 14:39LAN XingcanTag Attached: CMake
2015-07-09 14:45Brad KingNote Added: 0039114
2015-07-09 14:52patrikNote Added: 0039116
2015-07-09 16:01Brad KingNote Added: 0039117
2015-07-10 09:50Brad KingNote Added: 0039123
2015-10-26 10:26Jan RüeggNote Added: 0039676
2015-10-26 10:36Brad KingNote Added: 0039677
2016-06-10 14:29Kitware RobotNote Added: 0042658
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0039011)
patrik   
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.:
http://stackoverflow.com/questions/27039019/how-to-have-cmake-show-headers-that-are-not-part-of-any-binary-target-in-the-ide [^]
http://stackoverflow.com/questions/5957134/how-to-setup-cmake-to-generate-header-only-projects?lq=1 [^]

(0039112)
LAN Xingcan   
2015-07-09 14:39   
Ping?
(0039114)
Brad King   
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.
(0039116)
patrik   
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.
(0039117)
Brad King   
2015-07-09 16:01   
Design discussion like this is better held on the developer's mailing list:

 http://www.cmake.org/mailman/listinfo/cmake-developers [^]

where it can reach a broader audience.
(0039123)
Brad King   
2015-07-10 09:50   
Thanks for starting the thread. For reference, it is here:

 Header-only library targets
 http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/13636 [^]
(0039676)
Jan Rüegg   
2015-10-26 10:26   
Any update on this?

I agree with the comment here:
http://article.gmane.org/gmane.comp.programming.tools.cmake.devel/13673 [^]

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?
(0039677)
Brad King   
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.
(0042658)
Kitware Robot   
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.