One more try: HELP! VSTGUI 3.6 on OSX x64, possible? How?

[lkjb]

Do all files that include vstgui.h fail or are there maybe some that work?

They all fail, of course.

Well, it wasn't that much "of course" as you didn't mentioned it before.

If we can stick to advice from those who actually have compiled VSTGUI 3.6 for x64 on XCode or are at least experienced in XCode that'll help optimize the signal to noise here.

I'm sorry I tried to help.

[AdmiralQuality]

Do all files that include vstgui.h fail or are there maybe some that work?

They all fail, of course.

Well, it wasn't that much "of course" as you didn't mentioned it before.

I also didn't check to see if maybe tiny unicorns were causing the problem. Trying random things that don't make sense is not my M.O., I consider it "flailing".

If we can stick to advice from those who actually have compiled VSTGUI 3.6 for x64 on XCode or are at least experienced in XCode that'll help optimize the signal to noise here.

I'm sorry I tried to help.

Me too!

Any idea folks why the VSTSDK 3.6 tutorial project is compliling vstgui.h correctly when it's set to "Compile Sources As" "According To File Type", but my project won't compile it unless I change this to force C++?

XCode is like a box of chocolates.

[hibrasil]

forcing it is not going to work... you're going to need to compile those .mm as objc++

I think this might be something to do with the precompiled header. Maybe try disabling it / having a look at the PCH settings in tutorial vs yours? GCC_PRECOMPILE_PREFIX_HEADER

[AdmiralQuality]

forcing it is not going to work... you're going to need to compile those .mm as objc++

I think this might be something to do with the precompiled header. Maybe try disabling it / having a look at the PCH settings in tutorial vs yours? GCC_PRECOMPILE_PREFIX_HEADER

I'm looking at this at the target level now as I noticed some project settings don't match the projects. (For example I didn't have VSTGUI_ENABLE_DEPRECATED_METHODS=0 set in Preprocessor Macros for my individual targets, even though it was in the project. Man this is confusing compared to VS!)

And taking a look at the PCH stuff...

Both match (at the target level), only difference is the name of the Prefix Header (tutorial_Prefix.pch on the tutorial, xcode_vst_prefix.h on my project).

Any other differences?...

Compile Sources As (which I'm going to turn back to According To File Type).

Some optimization options are different in my Release version. That can't be it. (And I'm compiling the Development build anyway, which is the same.)

Prebinding was on. Off now to match tutorial.

Everything else matches exactly (excepting where the project name is used). Let's try this again...

Back to those same "Expected..." errors in vstgui.h

Now I'm removing #include <Carbon/Carbon.h> as suggested by C.Kerry, above. My pch file (xcode_vst_prefix.h) now matches tutorial's exactly, having only one line, #include "vstgui.h"

Compiling... errors. Strangely it seems to compile xcode_vstprefix.h 3 times. The first time through it complains about the line AFTER the BEGIN_NAMESPACE_VSTGUI line (vstgui.h 183) that "CFBundleRed does not name a type". So that would seem to indicate I need to put back the #include <Carbon/Carbon.h> But why doesn't the tutorial project need to do this? Several more of the same error for CGContextRef, CGImageRef, etc. And then the 2nd time it says it's compiling xcode_vst_prefix.h, it goes back to that previous "Expected..." error on the BEGIN_NAMESPACE_VSTGUI line! WTF!?!

Okay, trying one more thing, let's turn off this precompiled header entirely and see what happens... (I understand how these work on VS in Windows but I'm frankly a little hazy as to why we define it explicitly in XCode, I'm used to it being completely automatic.)


Turning "Precompile Prefix Header" off for my target. (Assuming it won't hurt to leave the filename in Prefix Header? Or is that a safe assumption in this particular funhouse?)

Compiling (and yes, I clean all targets every time whenever nonsense like this is happening)...

Same errors, "CFBundleRef does not name a type", etc. Yet both vstgui.h and aeffguieditor.cpp #include <Carbon/Carbon.h>

So confused...

[hibrasil]

try changing your prefix header filename to .pch extension and update the xcode project accordingly.

Xcode does make sense eventually. I have similar gripes with VisualStudio, just because I don't use it all the time, like I do Xcode. But don't get me started on Xcode4!

EDIT - I noticed you are following CKs guidelines. Those are with Xcode4, so there may be things that don't apply to Xcode3. I can compile the tutorial on Xcode3 with the guidelines i posted originally just fine.

[AdmiralQuality]

try changing your prefix header filename to .pch extension and update the xcode project accordingly.

Xcode does make sense eventually. I have similar gripes with VisualStudio, just because I don't use it all the time, like I do Xcode. But don't get me started on Xcode4!

We're thinking the same. I just noticed that same thing and already tried changing it to .pch (which I'll keep that way). No difference. Back to the "Expected..." error.

IMHO VS 2008 is a thing of beauty. I've heard bad things about 2010 and above, which is why I haven't "up"graded. (And yes, I've also heard to fear XCode 4, the other half of why I'm not interested in migrating to it until I have absolutely no choice.)

[lkjb]

I also didn't check to see if maybe tiny unicorns were causing the problem.

You mentioned that you get errors although your settings are the same as in the tutorial project. If everything's the same and your setup still doesn't work maybe something magic is involved. Checking for tiny unicorns might not be so bad after all.

Me too!

Unfortunately your rudeness won't keep me from trying to help.

You can easily provoke these errors when precompiling the headers by adding an empty .m file (obj-C instead of the .mm obj-C++ file) to the VSTGUI (3.6) tutorial project. I wouldn't wonder if some content in cpp or header files might do the same (who knows what gcc/LLVM is really doing). Trying to disable compiling for your files and enabling one after the other might help finding 'bad' files that mess up the compiler. At least you can exclude one possible cause for this if it still won't work with only the VSTGUI files compiling.

Also compiling VSTGUI 3.6 didn't seem to work out of the box in my setup (XCode 3.2.6 & OS X 10.6.8 like yours). I got the errors mentioned earlier in this (and other) threads. Can you give any insights about your setup that might cause it to build without errors. I barely dare to ask whether you might have downloaded VSTGUI 4.0 by mistake which works without changes.

[AdmiralQuality]

Did you get VSTGUI 3.6 rc2 from sourceforge? It has a sample project called "tutorial", which compiled for me in x86_64 without any changes.

So, I can get by these errors by forcing it to consider all files C++. But that of course isn't correct as I'll run into trouble on the .mm file. (And again, the tutorial project doesn't have this problem so why do I?)

Does Obj-C use .h for its include files too? If so, how does XCode know whether an include file is C, C++ or Obj-C?

Goddamned tiny unicorns!

[AdmiralQuality]

Another question. Is there any way to tell XCode what file is what type on a per-file basis? Or the only choice by extension, or force them all to one language?

This is really weird. I may give up and rebuild my project into the tutorial project. But I'd like to understand what's going on here.

[hibrasil]

Another question. Is there any way to tell XCode what file is what type on a per-file basis? Or the only choice by extension, or force them all to one language?

This is really weird. I may give up and rebuild my project into the tutorial project. But I'd like to understand what's going on here.

Don't think so. Here's an idea to try:

In the build results window, option click and "Open these results as a transcript file" on the failed build. Do the same on the successful build and compare the arguments that are being passed for the files in question... i.e. this kind of thing...

Code: Select all

ProcessPCH++ /var/folders/S5/S5DVIeVyEB4cDTiXQaUDGE+++TM/-Caches-/com.apple.Xcode.502/SharedPrecompiledHeaders/tutorial_Prefix-cksjwdivejidvcbpdogioslvhszo/tutorial_Prefix.pch.gch tutorial_Prefix.pch normal x86_64 objective-c++ com.apple.compilers.gcc.4_2
cd /Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac
setenv LANG en_US.US-ASCII
/Developer/usr/bin/gcc-4.2 -x objective-c++-header -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -DVSTGUI_ENABLE_DEPRECATED_METHODS=0 -mfix-and-continue -fvisibility-inlines-hidden -mmacosx-version-min=10.5 -gdwarf-2 "-I/Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac/build/tutorial.build/Debug/tutorial 2 vstsdk 2.4.build/tutorial 2.hmap" -F/Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac/build/Debug -I/Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac/build/Debug/include -I../vstsdk2.4 "-I/Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac/build/tutorial.build/Debug/tutorial 2 vstsdk 2.4.build/DerivedSources/x86_64" "-I/Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac/build/tutorial.build/Debug/tutorial 2 vstsdk 2.4.build/DerivedSources" -c /Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac/tutorial_Prefix.pch -o /var/folders/S5/S5DVIeVyEB4cDTiXQaUDGE+++TM/-Caches-/com.apple.Xcode.502/SharedPrecompiledHeaders/tutorial_Prefix-cksjwdivejidvcbpdogioslvhszo/tutorial_Prefix.pch.gch

CompileC "build/tutorial.build/Debug/tutorial 2 vstsdk 2.4.build/Objects-normal/x86_64/aeffguieditor.o" /Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac/../../aeffguieditor.cpp normal x86_64 c++ com.apple.compilers.gcc.4_2
cd /Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac
setenv LANG en_US.US-ASCII
/Developer/usr/bin/gcc-4.2 -x c++ -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks -O0 -Wreturn-type -Wunused-variable -DVSTGUI_ENABLE_DEPRECATED_METHODS=0 -mfix-and-continue -fvisibility-inlines-hidden -mmacosx-version-min=10.5 -gdwarf-2 "-I/Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac/build/tutorial.build/Debug/tutorial 2 vstsdk 2.4.build/tutorial 2.hmap" -F/Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac/build/Debug -I/Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac/build/Debug/include -I../vstsdk2.4 "-I/Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac/build/tutorial.build/Debug/tutorial 2 vstsdk 2.4.build/DerivedSources/x86_64" "-I/Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac/build/tutorial.build/Debug/tutorial 2 vstsdk 2.4.build/DerivedSources" -include /var/folders/S5/S5DVIeVyEB4cDTiXQaUDGE+++TM/-Caches-/com.apple.Xcode.502/SharedPrecompiledHeaders/tutorial_Prefix-bpziwrtrbsqccpdyvojrqdnjocfd/tutorial_Prefix.pch -c /Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac/../../aeffguieditor.cpp -o "/Users/oli/Downloads/vstgui_360/vstgui/tutorial/mac/build/tutorial.build/Debug/tutorial 2 vstsdk 2.4.build/Objects-normal/x86_64/aeffguieditor.o"

[lkjb]

Did you get VSTGUI 3.6 rc2 from sourceforge? It has a sample project called "tutorial", which compiled for me in x86_64 without any changes.

Yes, the only thing I did was putting the vst sdk files in the tutorial folder. The project loaded with GCC 4.2 which won't work with the set 10.4 Base SDK. Changing to GCC 4.0 works in 32-bit but not in 64-bit. At best I get some linker errors that nsViewScrollRect and others aren't found (when Cocoa is used).

Have you tried compiling without a precompiled header (e.g. comment the vstgui include)? I don't think the errors disappear but they might be better trackable.

[gnjp]

I went through this a few years back so I grabbed
a clean version of 3.6 and whipped this up for you.

vstgui3.6_x64.zip

Add the VST2.4 SDK and the XCode tutorial should compile
straight away as a 64bit version. Had to make a couple
of changes (search MYCHANGE).

best
Gary
Mellowmuse Software
www.mellowmuse.com

[AdmiralQuality]

I went through this a few years back so I grabbed
a clean version of 3.6 and whipped this up for you.

vstgui3.6_x64.zip

Add the VST2.4 SDK and the XCode tutorial should compile
straight away as a 64bit version. Had to change make a couple
of changes (search MYCHANGE).

best
Gary
Mellowmuse Software
www.mellowmuse.com

Thanks Gary but I'm not having a problem with the VSTGUI tutorial. It's my own project (that I've tried to make match the tutorial in every way) that's giving me weirdness.

hibrasil, I'll get back to you in a bit with the compiler output. (I've already looked at it and didn't see any glaring differences but another set of eyes never hurts.)

And yes lkjb, I need to try this one more time with PCH turned off. Will get back to you shortly with those results as well, just have some errands to run in the real world first.

Thanks all!

[AdmiralQuality]

Just an update for you. By turning off the precompiled header entirely I've at least been able to get it to start compiling (odd as I'm sure I tried that before), though now I'm seeing those same errors but now further down the list of errors. It's as if the PCH wasn't compiling because of errors AFTER it was compiled, which totally threw me off. Anyway, I'll deal with that error when I get to it, now that I'll see the actual context of where it was included.

Now most of my errors seem to be in my custom VSTGUI controls, which seem to require VSTGUI_ENABLE_DEPRECATED_METHODS set to 1 instead of unset as several of you have mentioned above. That's a big problem for me as now the functions I subclassed (to make things like my knobs with detents, freewheeling, an actually working circular-relative mode and other extended functionality) will no longer exist. Things like CKnob::mouse, CKnob::valueToPoint, CKnob::valueFromPoint, etc.

So I've got some work to do. Worst case, I'm going to have to re-do all those custom controls. Yikes, that's years of testing thrown out the window! I'm hoping there's an easier way.

Right now I'm just trying to figure out why VSTGUI_ENABLE_DEPRECATED_METHODS seems to be unset even though I'm setting it to 1 in my project settings. (I wish I could just roll over a macro like in Visual Studio and see what it expands to!) Hmmmmm...

[Tale]

Right now I'm just trying to figure out why VSTGUI_ENABLE_DEPRECATED_METHODS seems to be unset even though I'm setting it to 1 in my project settings. (I wish I could just roll over a macro like in Visual Studio and see what it expands to!) Hmmmmm...

I think you can view the GCC command line when building from within Xcode (in the build results window). Any macros you have defined in your project settings should be right there in the GCC command line.