Error when installing targets and exports in 3.19.1

Usage
#1

I’m using the following fragments to install targets and exports in a number of projects.

install(TARGETS myproj EXPORT myproj 
  ARCHIVE DESTINATION ${CMAKE_INSTALL_LIBDIR} COMPONENT development
  LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} COMPONENT runtime NAMELINK_SKIP
  RUNTIME DESTINATION ${CMAKE_INSTALL_BINDIR} COMPONENT runtime
)

if(MYPROJ_BUILD_SHARED_LIBS)
  install(TARGETS myproj  EXPORT myproj  LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} COMPONENT development NAMELINK_ONLY)
  if(MSVC)
    install(FILES $<TARGET_PDB_FILE:myproj > DESTINATION ${CMAKE_INSTALL_BINDIR} CONFIGURATIONS Debug RelWithDebInfo COMPONENT debug)
  endif()
endif()

This has worked literally for the last years. Until recently I got an error message from a user that used CMake 3.19.1

```
-- Configuring done
CMake Error: install(EXPORT "myproj" ...) includes target "myproj" more than once in the export set.
-- Generating done
```

Is the error on my side and I should avoid repeating the EXPORT myproj part when building shared libraries or is that a regression in 3.19.1?

Thanks in advance, Cheers Volker

#2

It smells like a regression, but there should be no reason to have a separate install() command for the target as it should just be a no-op on static builds anyways. The PDB installation should be guarded by MSVC (or MinGW) though.

Cc: @kyle.edwards

#3

BTW, I found many libraries have this same issue.

#4

If it’s a prevalent pattern, we should definitely look at fixing it. Is there a full project that can be pointed at so we can test any fixes?

#5

CMake >3.12 includes a new option NAMELINK_COMPONENT that can be used to do this in one command. As this was a common workaround to separate namelinks into runtime and development components on older CMake versions, it would be nice if this change in behavior since 3.19 could be protected by a policy.

#6

Cc: @kyle.edwards @brad.king Potential 3.19 regression.

#7

Related PR: https://github.com/microsoft/vcpkg/pull/14716

#8

Cc: @craig.scott @dbahadir

This bisects to CMake MR 5352. I’ve opened CMake Issue 21529 to record this regression.

#9

Thanks to all for handling and fixing this issue.