(0039011)
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.:
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 (reporter)
2015-07-09 14:39

Ping?

(0039114)
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.

(0039116)
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.

(0039117)
Brad King (manager)
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 (manager)
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 (reporter)
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 (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.

(0042658)
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.

Notes
(0039011) 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.: 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 (reporter) 2015-07-09 14:39	Ping?

(0039114) 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.

(0039116) 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.

(0039117) Brad King (manager) 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 (manager) 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 (reporter) 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 (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.

(0042658) 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

Relationships