Windows Post-Build Script in the new system


#1

The new Windows build system is a bit confusing for post-build copying of binaries. Our previously working script was this:

copy /Y "$(OutDir)\$(TargetFileName)" "$(OutDir)\$(TargetName).vst3"
copy /Y "$(OutDir)\$(TargetFileName)" "$(OutDir)\$(TargetName).aaxplugin"
copy /Y "$(OutDir)\$(TargetFileName)" "C:\Program Files\Common Files\VST3\$(TargetName).vst3"
xcopy "$(TargetPath)" "C:\Program Files\VSTPlugins\Unfiltered Audio" /Y

That will now copy a whole bunch of build noise into the VSTPlugins folder. The Projucer doesn’t seem to have per-project build settings. What are the best practices now for creating a functioning post-build copy script?


#2

Anyone else run into this? It seems like a fairly major issue for Windows developers.


#3

Bumping this again. In general, it seems like there’s a lack of information regarding the new system.

  1. What’s the best practice for post-build copying?

  2. Why can’t we access File Property pages anymore in Visual Studio? Try right-clicking on a file and selecting “Properties”. We need this as we have a required .rc file for our DRM system. We need to open its page and change it from “C++ Source” to “Resource Compiler” every time we re-JUCE. Since we can’t do that anymore, we had to create a hacky script to modify the solution every time it needs resaved.

  3. What are the advantages of this new system, aside from smaller binaries? Right now, it seems like everything became more complicated to manage and a whole lot slower to compile/link.


#4

This is the same behaviour on macOS, right? See, for example, this post:

I think something similar should be done with MSVC. You could use the $(ProjectName) build script variable.


Post build step should be ignored for "shared code"
#5

On Mac, we don’t need a post-build script since it automatically copies the binaries to the correct user folders.

On Windows, I think the deployment target options page should have an option for a VST2 path. It should copy the VST2 binary there. The VST3 and AAX paths on Windows are constant and not user-defined, so that shouldn’t need an option.

That would solve #1. #2 is another big issue with the new system.


#6

I bump this subject because I think the Projucer should provide options for copying the VST/AAX binairies in given folders like with Mac OS X. With all the recent changes on VS projects structure, it is now even more important that it was before.


#7

Before the structure changes in VS projects, I could just put the vstplugins folder in binary location, but now with all the new folders generated, I need to do this in the post build section for say the VST2 format only :

if "$(ProjectName)"=="$(SolutionName)_VST" copy /Y "$(TargetDir)\$(TargetName).dll" "c:\vstplugins\musical entropy\$(TargetName).dll"


#8

I’m bumping this up as it actually prevents from manually copying aax plugin bundles in the Post-build script, as the bundle is constructed after the Post-build script defined in Projucer, so you just don’t have a bundle to copy.

It would be very nice to have the option, in Projucer, to define plugin installation directories for Visual Studio projects, just like for xcode projects, and to have the copy automatically done in the default post-build script.


#9

I agree, and since it is done automatically on macOS, it would be great for Windows builds and more generally for people developing plug-in on Windows to have something equivalent


#10

OK, this is on develop now. Please see this thread.