smtg_add_plugin_resource inconsistent between platforms

SDK for VST 3 audio plug-in and host development.
Post Reply
User avatar
pongasoft
Posts: 115
Joined: Sun Mar 11, 2018 5:57 pm
Location: Las Vegas, USA
Contact:

smtg_add_plugin_resource inconsistent between platforms

Post by pongasoft »

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

Code: Select all

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:

Code: Select all

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:

Code: Select all

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

signalsmith
Posts: 11
Joined: Tue Dec 11, 2018 10:19 am

Re: smtg_add_plugin_resource inconsistent between platforms

Post by signalsmith »

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?

User avatar
pongasoft
Posts: 115
Joined: Sun Mar 11, 2018 5:57 pm
Location: Las Vegas, USA
Contact:

Re: smtg_add_plugin_resource inconsistent between platforms

Post by pongasoft »

signalsmith wrote:
Wed Sep 09, 2020 8:22 am
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

Code: Select all

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 ... .cmake#L28) to override a compile option set in PlatformToolset.cmake that was causing huge number of unecessary warnings (-Wsuggest-override)

rhansen
Posts: 27
Joined: Mon Jun 20, 2016 7:43 am
Location: Hamburg

Re: smtg_add_plugin_resource inconsistent between platforms

Post by rhansen »

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é

User avatar
pongasoft
Posts: 115
Joined: Sun Mar 11, 2018 5:57 pm
Location: Las Vegas, USA
Contact:

Re: smtg_add_plugin_resource inconsistent between platforms

Post by pongasoft »

rhansen wrote:
Wed Sep 09, 2020 2:28 pm
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).

Code: Select all

// 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

Code: Select all

        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.

signalsmith
Posts: 11
Joined: Tue Dec 11, 2018 10:19 am

Re: smtg_add_plugin_resource inconsistent between platforms

Post by signalsmith »

rhansen wrote:
Wed Sep 09, 2020 2:28 pm
What is the use case for putting an absolute file path into that function?
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.

Post Reply