Introjucer+RTAS+Windows broken

[yairadix]

(based on git tip)

Hi,

The Introjucer generated plugin for Visual Studio 2010 fails to build with RTAS.

JucePlugin_WinBag_path is being defined to \"STUFF\" instead of "STUFF" and so juce_RTAS_Wrapper.cpp fails to parse at

Code: Select all

#pragma comment(lib, PT_LIB_PATH "DAE.lib")


At jucer_AudioPluginModule.h:

Code: Select all

        exporter.msvcExtraPreprocessorDefs.set ("JucePlugin_WinBag_path", CodeHelpers::addEscapeChars (rtasFolder.getChildFile ("WinBag")
                                                                                                                 .toWindowsStyle().quoted()));


The .quoted() needs to move to after the escaping.

Additionally, I use relative paths for SDKs, and I needed to add an additional "../../" at

Code: Select all

RelativePath rtasFolder (getRTASFolder (exporter).toString(), RelativePath::projectFolder);


to make it work.

Cheers, Yair

[jules]

Excellent stuff, much appreciated! I've checked in something that should hopefully sort that out..

[yairadix]

great, thx!

one more thing - the juce_RTAS_...cpp files are lacking the stdcall calling convention settings.

[jules]

one more thing - the juce_RTAS_...cpp files are lacking the stdcall calling convention settings.

Really? Looks to me like that setting is correctly set in the project (?)

[yairadix]

This seems to be the case here at least for MSVC2010.

Two lines seem suspicious:

Code: Select all

addFilesToCompile (groups.getReference(i), *cppFiles, *headerFiles, false);


"false" for the argument "useStdCall". and

Code: Select all

if (useStdcall)
{
    jassertfalse;
}


If I replace those lines with a quick and dirty work-around:

Code: Select all

if (file.getFileName().contains("juce_RTAS") && !file.getFileName().contains("WinUtilities"))
    e->createNewChildElement ("CallingConvention")->addTextElement ("StdCall");


Then all works fine. Of course that's most probably not the best way to solve it

Another thing - I'm afraid the fix for the relative PT SDK paths didn't work right.
I have VST sdk path set to ..\..\vstsdk3 and trying ..\..\PT_80_SDK for RTAS now doesn't work for includes. Looking on the include paths It seems to be adding way more "..\" than necessary and hackishly working around it by setting to "PT_80_SDK" with no "..\..\" makes the includes work right but then it fails to find the libs in the right spot..

[yairadix]

The relative RTAS paths issue seems to be caused due to call

Code: Select all

exporter.addToExtraSearchPaths (rtasFolder.getChildFile (p[i]));


to addToExtraSearchPaths which does an additional rebaseFromProjectFolderToBuildTarget.

Code: Select all

void ProjectExporter::addToExtraSearchPaths (const RelativePath& pathFromProjectFolder)
{
    RelativePath localPath (rebaseFromProjectFolderToBuildTarget (pathFromProjectFolder));

    const String path (isVisualStudio() ? localPath.toWindowsStyle() : localPath.toUnixStyle());
    extraSearchPaths.addIfNotAlreadyThere (path, false);
}


replacing addToExtraSearchPaths line with

Code: Select all

exporter.extraSearchPaths.add (rtasFolder.getChildFile(p[i]).toWindowsStyle());


seems to solve the problem.

[jules]

Ah sorry, I was looking at the VS2008 project. I've made some tweaks now - hopefully it should work ok.

[yairadix]

this part works good now, thx!

The issue of PT_SDK includes still remains though, it's a simple one liner to fix it:

Code: Select all

-    exporter.addToExtraSearchPaths (rtasFolder.getChildFile (p[i]));
+    exporter.extraSearchPaths.add (rtasFolder.getChildFile (p[i]).toWindowsStyle());


(addToExtraSearchPaths seems to do a relative path conversion assuming the wrong base..)

[jules]

Ah, I think it was probably my last fix that broke that.. I think we need to roll-back the start of the function like this:

Code: Select all

    static void addExtraSearchPaths (ProjectExporter& exporter)
    {
        RelativePath rtasFolder (getRTASFolder (exporter).toString(), RelativePath::projectFolder);


(..otherwise it'll adjust the relative path twice)

Thanks! (We'll get there in the end!)

[yairadix]

We'll get there in the end!

All works fine now, thx!

[yairadix]

Oy, it looks like when fixing it for Windows we broke it (relative path to RTAS SDK) in Mac.

Here's the diff of a quick-n-dirty fix to make it work on mac:

Code: Select all

-        exporter.xcodeExtraLibrariesDebug.add   (rtasFolder.getChildFile ("MacBag/Libs/Debug/libPluginLibrary.a"));
-        exporter.xcodeExtraLibrariesRelease.add (rtasFolder.getChildFile ("MacBag/Libs/Release/libPluginLibrary.a"));
+        RelativePath rtasFolderB(getRTASFolder (exporter).toString(), RelativePath::projectFolder);
+        exporter.xcodeExtraLibrariesDebug.add   (rtasFolderB.getChildFile ("MacBag/Libs/Debug/libPluginLibrary.a"));
+        exporter.xcodeExtraLibrariesRelease.add (rtasFolderB.getChildFile ("MacBag/Libs/Release/libPluginLibrary.a"));


Would it be better to just place my SDKs at ~/SDK like you do or is the bug-finding desired? cheers, Yair

[jules]

Thanks! I'll take a look. And yes, the bug-finding is appreciated!

[steffen]

Some of those changes seem to have broken the RTAS builds in VS2005.

I am getting a compile error in the RTAS wrapper

Code: Select all

1>Compiling...
1>juce_RTAS_Wrapper.cpp
1>..\..\..\juce\modules\juce_audio_plugin_client\RTAS\juce_RTAS_Wrapper.cpp(108) : error C2017: illegal escape sequence


This line doesn't seem to accept the double-backward-slashes in the JucePlugin_WinBag_path

Code: Select all

#pragma comment(lib, PT_LIB_PATH "DAE.lib")

If I change that to single forward slashes in the project properties, the wrapper will compile, but linking fails with

Code: Select all

1>Linking...
1>juce_RTAS_WinExports.def : error LNK2001: unresolved external symbol NewPlugIn
1>juce_RTAS_WinExports.def : error LNK2001: unresolved external symbol _PI_GetRoutineDescriptor


Any idea how to fix this?

[jules]

Erm.. I guess it at line 310, it just doesn't need the bit where it adds the escape-characters, so:

Code: Select all

        exporter.msvcExtraPreprocessorDefs.set ("JucePlugin_WinBag_path",
                                                getRTASFolderRelativePath (exporter)
                                                    .getChildFile ("WinBag").toWindowsStyle().quoted());


..does that work?

[steffen]

It turned out that in VS2005, you do have to escape the slashes *and* the surrounding quotes when defining the winbag path in the project properties:

Code: Select all

JucePlugin_WinBag_path=\"D:\\Develop\\zplane\\SDKs\\PT_80_SDK\\WinBag\"

However that does not work in VS2010, you get a similar "illegal escape sequence" error. It looks like VS2010 automatically escapes the quotes before passing them to the command line, while VS2005 doesn't.