Xcode 10 feedback

I think you may need to re-copy the SDK you were using before back into Xcode’s SDK folder. And for some reason, reset all the other locations in Producer, by selecting ‘…’ and mouse clicking the appropriate folders.
That’s what I had to do anyway, ¯| (ツ) /¯
edit someone posted a link to download all the SDKs a while ago I can’t remember where at the mo, sorry.

The SDKs are here: https://github.com/phracker/MacOSX-SDKs
Copying in them will work, but it seems a bit “forced”. There has to be a reason why they go away from Xcode. Can’t we just add the 10.14 SDK in Projucers list ?
To be honest I’m a bit confused about the sdk version vs deployment target, we still have to support at least Osx 10.10 or 10.11, how will that work out if we use the 10.14 SDK, and how will the new versions of osx play with the old SDKs.
Sorry, I guess this is a bit off topic for this “xcode 10” post

1 Like

Quick question, is your autocompletion for includes not working as well?

If you type in #include<>

Then begin to insert your library name, like vector for example, do you get an autocompletion for it? I’m not getting any for most libraries.

Hey @DaveH. I had the same problem(file not found). In my case, I’ve set up JUCE incorrect. I’ve copied only Projucer.dmg firstly, but If I copy whole folder(projucer.dmg should be inside it) then it works correct.

@maslenkov I’ve completed two products with my current Mac Juce installation, but a latest-ish Mac update or something screwed up my Projucer folder pointers. Kinda weird though, I don’t quite understand what happened TBH.

1 Like

Take a look at this thread…

Yeah, that’s exactly the problem. Don’t use the ~ character for the home directory. Projucer correctly uses the full path if you click on ‘…’ to change it.

Sod this, I’m going back to 9.4.1.
I’m now getting the a crashes as soon as I start typing #include <emm…> - it can be anything to be honest. It eventually comes up with a crash log:

“Details: Path must be absolute but is not: …/…/JuceLibraryCode”

Process:               Xcode [3101]
Path:                  /Applications/Xcode.app/Contents/MacOS/Xcode
Identifier:            Xcode
Version:               10.0 (14320.25)
App Item ID:           497799835
App External ID:       828536089
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Xcode [3101]
User ID:               501

Date/Time:             2018-10-01 16:41:10.044 +0100
OS Version:            Mac OS X 10.13.6 (17G65)
Report Version:        12
Anonymous UUID:        D81061EC-2C90-6D01-365B-316C11F961D3


Time Awake Since Boot: 8200 seconds

System Integrity Protection: enabled

Crashed Thread:        9  Dispatch queue: -[DVTTextCompletionDataSource init] (QOS: UNSPECIFIED)

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
ProductBuildVersion: 10A255
ASSERTION FAILURE in /Library/Caches/com.apple.xbs/Sources/DVTFrameworks/DVTFrameworks-14317.18/DVTFoundation/FilePaths/DVTFilePath.m:908
Details:  Path must be absolute but is not: ../../JuceLibraryCode
Object:   <DVTFilePath>
Method:   +filePathForPathString:
Thread:   <NSThread: 0x7fdc4f440dd0>{number = 44, name = (null)}
1 Like

Yep, that’s the same crash I ran into.

I just tried the Xcode 10.1 beta and it still doesn’t recompile when a file has changed in a module (referenced folders?). Sad.

Anyone getting insta-crashes as well? I open a JUCE session, make a few tweaks and it instantly crashes and is totally repeatable, not random.

auto complete is slow as molasses here. no crashes though…

Yeah, what does the eventual crash log say? (mine takes a few minutes to appear, through embarrassment I expect! :slight_smile:)

After upgrading to Xcode 10, swapping buffers in openGL suddenly takes up almost a whole CPU core. Anyone else experience this?
After downgrading to 9 it works as expected.

You’ve probably exposed one of Apple’s redacting techniques. i.e. put massive for-loops in code they don’t like…:grinning: I’m only joking…:face_with_monocle:

Remember you’re under NDA with Pace about the details of their SDK.

Thanks for the information @hill_matthew I didn’t know it was part of the NDA since it was in the release note… I deleted my post.

Some very broad advice is to keep a copy of Xcode 9 around for now. Renaming Xcode.app to Xcode_9.app should be enough.

Assuming that most people here will want to support older versions of OSX that still support 32-bit apps then doesn’t “for now” turn into “for the next few years”? Or have I missed something?

In Apple-world, 32 bit is no longer such a big issue, the last 32-bit only was 10.6.8 (superseded by 10.7 in 2011), and from 10.8 it was 64-bit only. So the only people who care, are the ones with ProTools < PT10, because of their 32-bit accellerator hardware.

(just as a side note, don’t want to derail the thread)

1 Like