IntroJucer AU project won't build


#1

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


#2

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…


#3

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


#4

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?


#5

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


#6

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


#7

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


#8

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.


#9

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