[CMake] Specify extra files for display in IDE

[Daniel Eiband]

Hi,

I tried to add interface sources to interface libraries with both, the CMake 3.11.18040201-MSVC_2 integration of Visual Studio (with Ninja), which I’m using most of the time, and the “Visual Studio 15 2017 Win64” generator of CMake 3.12.1:


-       The Visual Studio integration shows the target in the “CMake Targets View”, but it contains only one file: CMakeLists.txt. There is no difference if I set header only interface sources or no sources. If this differs from the intended behavior of the CMake generators then I will follow this up with the Visual Studio team.

-       The Visual Studio generator doesn’t show interface libraries at all.

Is this the intended behavior of the Visual Studio generator?

Unclear to me is, what the semantics of header only interface sources are? Should headers be INTERFACE_SOURCES? I don’t see a point in propagating them to targets which link to the interface library. To my understanding this is what interface source means. Maybe there is more to it. When headers of the public interface of a library are supposed to be interface sources, then this means, that I should put headers of regular libraries in the PUBLIC section, right?

Daniel

From: Eric Noulard [mailto:eric.noulard at gmail.com]
Sent: Mittwoch, 5. September 2018 11:22
To: Daniel Eiband <daniel.eiband at brainlab.com>
Cc: CMake Mailinglist <cmake at cmake.org>
Subject: Re: [CMake] Specify extra files for display in IDE


Le mer. 5 sept. 2018 à 11:00, Daniel Eiband <daniel.eiband at brainlab.com<mailto:daniel.eiband at brainlab.com>> a écrit :
Hi,

I managed to solve the presentation of object libraries by renaming the targets and hiding certain targets in folders. I think this solution is acceptable.

The issue with the display of header only libraries in IDEs, which are implemented as interface libraries, is still unsolved. The add_library() command doesn’t accept any sources.

For an interface library you can add sources with

target_sources(yourlib INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/whatever.h)

You need the INTERFACE keyword though: https://cmake.org/cmake/help/latest/command/add_library.html#interface-libraries

is this not working for you?

Could you provide a strip-down archive which exhibit this issue I may try it on my side?

Also setting the SOURCES property of an interface library target is rejected by CMake.

This is because you can only populate INTERFACE_SOURCES on an INTERFACE target:
https://cmake.org/cmake/help/latest/prop_tgt/INTERFACE_SOURCES.html
https://cmake.org/cmake/help/latest/command/target_sources.html#command:target_sources


I haven’t found any other way of adding the files to the interface library so that they are presented in the IDE.

Like I said in a previous email on my side, interface library (INTERFACE) sources are displayed in vscode and qtcreator, may be the fact that they are not displayed by Visual Studio
is a Visual Studio bug?

By the way there is an old issue on this subject:
https://gitlab.kitware.com/cmake/cmake/issues/15234


I know the workaround of adding an empty custom target. This is however not really satisfying, because Visual Studio for example displays them with a completely different icon and the suffix “(utility target)”. Doesn’t look like a C++ library any longer. It also sort of highlights the library because of the non-C++ icon and I have to hide even more targets (the real interface libraries).

From a CMake interface perspective this is also an asymmetry: Why can I add arbitrary files to executable and static/shared library targets being displayed in IDEs without contributing to the build artifact while this is not possible for interface libraries? I think, the restriction on interface libraries should not be that they don’t have any source files. Interface libraries must not have source files which produce build artifacts.

Agreed and I think it would more "natural" to be able to simply
target_sources / add_library "as usual" and promote SOURCES to INTERFACE_SOURCES automatically since the target is an INTERFACE lib.


Is this worth an enhancement bug or has this already been discussed?

The only one I am aware of is this one:
https://gitlab.kitware.com/cmake/cmake/issues/15234

--
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cmake.org/pipermail/cmake/attachments/20180905/842b634d/attachment-0001.html>