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.noul...@gmail.com]
Sent: Mittwoch, 5. September 2018 11:22
To: Daniel Eiband <daniel.eib...@brainlab.com>
Cc: CMake Mailinglist <cmake@cmake.org>
Subject: Re: [CMake] Specify extra files for display in IDE


Le mer. 5 sept. 2018 à 11:00, Daniel Eiband 
<daniel.eib...@brainlab.com<mailto:daniel.eib...@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
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Reply via email to