XCode 3 problems compiling demo AU

Audio Plugins
1

I just upgraded to Leopard and XCode 3 and I can’t build the demo AU. What am I doing wrong? I’m using the most current version from svn.

First, if I setup juce.xcconfig for 10.4 compatibility there is a compile error in AUBase:

/Developer/Examples/CoreAudio/AudioUnits/AUPublic/AUBase/AUBase.cpp:1306: error: ‘kAudioUnitRenderAction_PostRenderError’ was not declared in this scope

if I set up juce.xcconfig for 10.5 there is an error in the AU wrapper code, line 179 “ISO C++ forbids declaration of ‘type name’ with no type”:

2

Weirdness…

The error in the wrapper code had to do with the use of the uint8 type which is typedefed in juce_MathsFunctions.h. Something must be wrong here to make this happen. Please advise. Anyway, I changed uint8 to UInt8 and it builds fine using the 10.5 settings.

Now, of course I don’t want to target 10.5 only. As I said when I targeted 10.4 and use the 10.4 SDK (as laid out in juce.xcconfig) there was a build error in AUBase. The Core Audio SDK ReleaseNotes.rtf says this:

thus, the xcconfig file should read:

//  For 10.4 (and later) compatibility, use these instead:
 MACOSX_DEPLOYMENT_TARGET = 10.4
// SDKROOT = $(DEVELOPER_SDK_DIR)/MacOSX10.4u.sdk

//  For 10.5 (and later) compatibility, use these instead:
// MACOSX_DEPLOYMENT_TARGET = 10.5
 SDKROOT = $(DEVELOPER_SDK_DIR)/MacOSX10.5.sdk

And there you have it.

3

Nice one, thanks for that. Very strange about the uint8 stuff, I’m surprised that the compiler would have any trouble with anything like that.

4

Well, uint8, uint32, uint64, it’s the lot. Just depends on what you use I suppose. It stops me dead (using the 10.5 deploy 10.4 combo).

So, in the 10.5 SDK, there are now defines for all of these in cssmconfig.h like this:

#ifndef _UINT64 typedef uint64_t uint64; #define _UINT64 #endif

I would have thought we’d get double define warnings rather than not defined (I have 1584 from that ; ) but there you go. Doing a conditional define didn’t seem to help though, so I’m not sure juce’s version is masking the other?

Could the two be close enough to disrupt? If I do juce::uint64 that works, but in which case shouldn’t it find the OS define?

Bruce

5

I guess you could try a hack like “#define uint8 juce::uint8”…?

6

I suppose. I made my own types for 3 or 4 things I was using, in the same vein - I’m working with times in nanoseconds a lot, or video frame times. So that was an enforced improvement anyway ; )

The rest, I mostly just added the juce namespace to. It’s OK. Just weird. How can a non-defined type mask a namespace type? Maybe a GCC change rather than OS X?

Bruce