Smtg_add_plugin_resource inconsistent between platforms

I am trying to build my plugin with 3.7.0 and found an inconsistency between platforms:

function(smtg_add_plugin_resource target input_file)
    if(SMTG_LINUX OR (SMTG_WIN AND SMTG_CREATE_BUNDLE_FOR_WINDOWS))
     .....
        add_custom_command(TARGET ${target} POST_BUILD
            COMMAND ${CMAKE_COMMAND} -E copy
            ${CMAKE_CURRENT_LIST_DIR}/${input_file} # <===== ${CMAKE_CURRENT_LIST_DIR}/ added
            ${destination_folder}
        )
    elseif(SMTG_MAC) # <===== for mac use only ${input_file}
        target_sources(${target} PRIVATE ${input_file})
        set(destination_folder "Resources")
        if(ARGV2)
            set(destination_folder "${destination_folder}/${ARGV2}")
        endif()

        set_source_files_properties(${input_file} 
            PROPERTIES 
            MACOSX_PACKAGE_LOCATION "${destination_folder}"
        )
    endif()
endfunction()

The difference is that for Windows it uses ${CMAKE_CURRENT_LIST_DIR}/${input_file} but for macOS it uses ${input_file}. So if the input_file provided is absolute, it works on macOS but it fails on windows:

C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(149,5): 
error MSB3073: "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" 
-E copy D:/src/local/pongasoft/jamba/jamba-test-plugin/D:/src/local/pongasoft/jamba/jamba-test-plugin/resource/JambaTestPlugin.uidesc
 D:/Work/jamba-test-plugin/build/VST3/Debug/pongasoft_JambaTestPlugin.vst3/Contents/Resources [D:\Work\jamba-test-plugin\build\pongasoft_JambaTestPlugin.vcxproj]

I end up with a wrong path:


D:/src/local/pongasoft/jamba/jamba-test-plugin/D:/src/local/pongasoft/jamba/jamba-test-plugin/resource/JambaTestPlugin.uidesc
[       ${CMAKE_CURRENT_LIST_DIR}/            ][         ${input_file}                                                       ]

Yan

I just ran into this as well.

What file did you quote in your extract there, and is there a fix I can do locally to address the inconsistency?

I didn’t find a fix. I migrated from 3.6.9 which did not use the .vst3 folder format for Windows. So I left it that way (which means the SMTG_CREATE_BUNDLE_FOR_WINDOWS is set to OFF so the first IF is never executed).

But yes that is clearly an issue that needs to be fixed. One way to address it is to copy the file VST3_SDK/cmake/modules/AddSMTGLibrary.cmake into your own cmake folder (ex: your_project/cmake), fix the problem and add

list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}/cmake")

before including anything from VST in your cmake file. I did this in Jamba (https://github.com/pongasoft/jamba/blob/v5.0.0/jamba.cmake#L28) to override a compile option set in PlatformToolset.cmake that was causing huge number of unecessary warnings (-Wsuggest-override)

Hey,

the function smtg_add_plugin_resource is designed the way it only takes a relative file path. This makes sense for cross platform development. What is the use case for putting an absolute file path into that function?

Cheers,
René

Example of use case: you have a set of image resources that are common to all your projects and are outside the project itself (could live in another project that gets fetch at cmake configure time for example).

// resource outside
common_vst_images/xxx.png

// current project cmake file
set(COMMON_IMAGES_SRC "/.../common_vst_images")

// include common image (ex: company logo...)
smtg_add_plugin_resource("plugin" "${COMMON_IMAGES_SRC}/xxx.png")

I really don’t see the reason why you would assume it is relative and I don’t think you should and you don’t for the SMTG_MAC branch of the “if”…

I think it is safe to simply change

        add_custom_command(TARGET ${target} POST_BUILD
            COMMAND ${CMAKE_COMMAND} -E copy
            ${CMAKE_CURRENT_LIST_DIR}/${input_file} # <===== ${CMAKE_CURRENT_LIST_DIR}/ added
            ${destination_folder}
        )

to

        add_custom_command(TARGET ${target} POST_BUILD
            COMMAND ${CMAKE_COMMAND} -E copy
            ${input_file}
            ${destination_folder}
        )

because CMAKE_CURRENT_LIST_DIR contains the folder of the file calling the smtg_add_plugin_resource function so if it is relative it will work (because it is 100% equivalent to ${CMAKE_CURRENT_LIST_DIR}/${input_file}) and if it is absolute it will work as well.

For my use-case, I’m actually using ${CMAKE_CURRENT_LIST_DIR} myself as a flexible/portable approach to shared resource bundles, but it produces an absolute path.

I don’t want to be too much like this XKCD comic, so if you have a similarly flexible solution then I’m happy to change - but this approach seems decent to me, and it works on Mac.