IntroJucer AU project won't build

Hi Jules,

Can I please report a bug?

I’ve found that if you create a new AU project with IntroJucer, the project fails to
build properly (due to various C++ 11 complaints…) (XCode 4.6.3) - the work-around
is to modify project to set the C++ language dialect to “Compiler Default”.

HTH!

Pete

Well, just tried that and it works fine here…

Have you got some sort of weird custom compiler set-up? I just ask because of your comment that the juce_argv definitions caused a compiler error, when that code had been in the tree for years without anyone else hitting a problem…

Hi Jules!

The Introjucer problem was just using “out of the box” XCode/Juce - so that is weird. :slight_smile:
Not to worry however, as if anybody sees it, they’ll know what to do.

The Other issue - yes, that must be down to a complier strictness level in that particular project - in which case, please don’t worry too much about it.

Best wishes,

Pete

Hmm, it just seems a bit odd to me - regardless of which version of Xcode you’re running, I wouldn’t expect to see any errors. What exactly where the problems you hit?

Hi Jules,

Here is an extract of the build log, showing the two error types that are given!

XCode 4.6.3

Remember: fixed easily enough by changing the language dialect in the XCode project generated by the Introjucer, from “C++11 [-sdt=c++11]” to “Compiler Default”

The errors are caused by two files in CoreAudio: CADebugMacros.h, and AUCarbonViewBase.cpp …

In file included from /Applications/Xcode.app/Contents/Developer/Extras/CoreAudio/AudioUnits/AUPublic/AUBase/ComponentBase.h:45:
/Applications/Xcode.app/Contents/Developer/Extras/CoreAudio/PublicUtility/CADebugMacros.h:139:79: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal]
                        #define DebugMessage(msg)                                                                               DebugPrintfRtn(DebugPrintfFileComma "%s"DebugPrintfLineEnding, msg) FlushRtn
                                                                                                                                                                        ^
                                                                                                                                                                         
/Applications/Xcode.app/Contents/Developer/Extras/CoreAudio/AudioUnits/AUPublic/AUCarbonViewBase/AUCarbonViewBase.cpp:257:30: error: non-constant-expression cannot be narrowed from type 'short' to 'CGFloat' (aka 'float') in initializer list [-Wc++11-narrowing]
                                        HISize originalSize = { mBottomRight.h, mBottomRight.v };
                                                                ^~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Extras/CoreAudio/AudioUnits/AUPublic/AUCarbonViewBase/AUCarbonViewBase.cpp:257:30: note: override this message by inserting an explicit cast
                                        HISize originalSize = { mBottomRight.h, mBottomRight.v };
                                                                ^~~~~~~~~~~~~~
                                                                static_cast<CGFloat>( )
/Applications/Xcode.app/Contents/Developer/Extras/CoreAudio/AudioUnits/AUPublic/AUCarbonViewBase/AUCarbonViewBase.cpp:257:46: error: non-constant-expression cannot be narrowed from type 'short' to 'CGFloat' (aka 'float') in initializer list [-Wc++11-narrowing]
                                        HISize originalSize = { mBottomRight.h, mBottomRight.v };
                                                                                ^~~~~~~~~~~~~~
/Applications/Xcode.app/Contents/Developer/Extras/CoreAudio/AudioUnits/AUPublic/AUCarbonViewBase/AUCarbonViewBase.cpp:257:46: note: override this message by inserting an explicit cast
                                        HISize originalSize = { mBottomRight.h, mBottomRight.v };
                                                                                ^~~~~~~~~~~~~~
                                                                                static_cast<CGFloat>( )
3 errors generated.

So, I then wondered if this was because I’m using a different CoreAudio SDK to you?

It turned out that I was using the latest one from Feb 2012, but I re-installed this just in case there was an issue.

That revealed this problem in AUMIDIEffectBase.cpp

/Applications/Xcode.app/Contents/Developer/Extras/CoreAudio/AudioUnits/AUPublic/OtherBases/AUMIDIEffectBase.cpp:154:18: error: member 'MIDIEvent' found in multiple base classes of different types
                result = This->MIDIEvent(inStatus, inData1, inData2, inOffsetSampleFrame);

My solution (as from the last time I updated the CoreAudio SDK), was to modify that function as below:

static OSStatus		AUMIDIEffectBaseMIDIEvent(void *				inComponentStorage,
                                            UInt32					inStatus,
                                            UInt32					inData1,
                                            UInt32					inData2,
                                            UInt32					inOffsetSampleFrame)
{
	OSStatus result = noErr;
	try {
		AUMIDIEffectBase *This = static_cast<AUMIDIEffectBase *>(inComponentStorage);
		if (This == NULL) return paramErr;
		// MPC
		AUMIDIBase *lpThis = (AUMIDIBase*)This;
		result = lpThis->MIDIEvent(inStatus, inData1, inData2, inOffsetSampleFrame);
	}
	COMPONENT_CATCH
	return result;
}

Anyhow - the compiler problems still stand.

Hoping this helps you a bit! :slight_smile:

Best wishes,

Pete

Oh, that’s a well-known Apple blooper. You have to patch their crappy code for it to work:
http://rawmaterialsoftware.com/viewtopic.php?f=8&t=9888

Ha! :slight_smile: Not sure that explains the C++11 issue, however…?! :slight_smile:

What issue do you mean? It just looks like different compiler versions being picky over a few syntactic edge-cases to me… Turning off c++11 probably just relaxes the strictness and lets these things through, I guess.

Yeah, that is all I meant. As I say, not worth worrying about I suppose; except that for an AU/Plug-in project, you might wan the Introjucer to use a different compiler language dialect! :slight_smile:

Best wishes,

Pete