Introjucer+RTAS+Windows broken


#1

(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

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

At jucer_AudioPluginModule.h:

        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

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

to make it work.

Cheers, Yair


#2

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


#3

great, thx!

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


#4

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


#5

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

Two lines seem suspicious:

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

“false” for the argument “useStdCall”. and

if (useStdcall)
{
    jassertfalse;
}

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

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 :slight_smile:

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…


#6

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

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

to addToExtraSearchPaths which does an additional rebaseFromProjectFolderToBuildTarget.

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

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

seems to solve the problem.


#7

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


#8

this part works good now, thx!

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

-    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…)


#9

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:

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!)


#10

All works fine now, thx! :slight_smile:


#11

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:

-        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


#12

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


#13

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

I am getting a compile error in the RTAS wrapper

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

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

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?


#14

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

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

…does that work?


#15

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:

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.


#16

Ah! Ok, so how about this:

[code] String winbag (CodeHelpers::addEscapeChars (getRTASFolderRelativePath (exporter)
.getChildFile (“WinBag”)
.toWindowsStyle()).quoted());

    if (exporter.getName() == "Visual Studio 2005")
        exporter.msvcExtraPreprocessorDefs.set ("JucePlugin_WinBag_path", CodeHelpers::addEscapeChars (winbag.quoted()));
    else
        exporter.msvcExtraPreprocessorDefs.set ("JucePlugin_WinBag_path", CodeHelpers::addEscapeChars (winbag).quoted());[/code]

#17

That version worked in VS2005, but not in 2010. Did you insert the double escaping on purpose?

What worked for me was this code:

        String winbag = getRTASFolderRelativePath (exporter).getChildFile ("WinBag").toWindowsStyle();

        if (exporter.getName() == "Visual Studio 2005")
            exporter.msvcExtraPreprocessorDefs.set ("JucePlugin_WinBag_path", CodeHelpers::addEscapeChars (winbag.quoted()));
        else
            exporter.msvcExtraPreprocessorDefs.set ("JucePlugin_WinBag_path", CodeHelpers::addEscapeChars (winbag).quoted());

I haven’t tested it with SDK paths containing spaces though, and can’t test right now if the actual linking succeeds in VS2010.


#18

Yes, sorry, escaping it all twice was a typo. Have checked some code in now, if you want to try it.