Simulate downstream user for Windows CI and vcpkg problems

[jasjuang]

Currently, when I install pcl through vcpkg, it successfully installed but it's the old 1.9.1 release. My problem is when I link to it with a simple example like the below

CMakeLists.txt

cmake_minimum_required(VERSION 3.1)

project(Example)

set(PROJECT_SRCS ${PROJECT_SOURCE_DIR}/mycpp.cpp)

find_package( PCL REQUIRED )

add_executable(${PROJECT_NAME} ${PROJECT_SRCS})

target_link_libraries(${PROJECT_NAME} ${PCL_LIBRARIES})

mycpp.cpp

int main(){
  return 0;
}

I got error messages like this

CMake Error at C:/dev/vcpkg/installed/x64-windows/share/pcl/PCLConfig.cmake:679 (set_target_properties):
  Property INTERFACE_LINK_LIBRARIES may not contain link-type keyword
  "optimized".  The INTERFACE_LINK_LIBRARIES property may contain
  configuration-sensitive generator-expressions which may be used to specify
  per-configuration rules.

My first question: is this solved on the latest master?

If yes, can @UnaNancyOwen @claudiofantacci share with me your modified vcpkg pcl portfile that works with the latest pcl master? My attempt at #3202 is not successful. Or is there a way to patch it up so the 1.9.1 pcl in vcpkg is usable?

If we are not sure, may I suggest to add a check into the current Windows CI? Currently, it only checks the basic builds and unit tests. I think it will be amazing to add a few more lines to simulate how the downstream user will link to pcl and see if it's successful.

[jasjuang]

I found a temporary workaround in the comments here

[SergioRAgostinho]

My first question: is this solved on the latest master?

I personally have no idea. I interface often with Sergey but its just experiments between *nix platforms. Him Linux, me Mac. I believe @SunBlack runs our master branch under windows platforms and I suspect if this was a problem he would have brought it up by now.

Or is there a way to patch it up so the 1.9.1 pcl in vcpkg is usable?

The vcpkg team can and has in the past applied patches on top of 1.9.1 to get it working in their distribution. From our side, if it's a minor CMake thing we can also release a 1.9.2 addressing this. However two things: a big part of 1.10 is done already, although there are some annoying blocking issues that still need to be addressed, the timing is just not great; it would require confirming that this is not a vcpkg specific issue, and if it is, it would be good to have a clear explanation on why it is failing when it is shipped through them.

[Neumann-A]

@SergioRAgostinho: As somebody who commits a lot to vcpkg and also has done a lot in the linkage area I can say to you: It is a PCL issue.

From(#2989 (comment))

So, finally I walk around the problem by commenting out the following line in PCLConfig.cmake:
#list(APPEND PCL_${COMPONENT}_LIBRARIES "${${LIB}_LIBRARIES}")

using any ${LIB}_LIBRARIES variable must expect debug/optimized keywords when using it to set INTERFACE_LINK_LIBRARIES and PCL is not guarding against that in the PCLConfig.cmake. It is common CMake practice to use select_library_configurations to set ${LIB}_LIBRARIES which introduces the keywords. So in the PCL config ${LIB}_LIBRARIES must be put in a foreach loop and checked for the keywords. If the keyword is found the next entry can be simply wrapped by a configuration dependent generator expression .e.g $<$<CONFIG:DEBUG>:entry> or $<$<NOT:$<CONFIG:DEBUG>>:entry> .

If PCL is using targets anyway and is also using CMake to automatically generate the targets, setting INTERFACE_LINK_LIBRARIES manually should not even be necessary if the linkage in the CMakeLists.txt for the target is correctly set.