CMake calls through to xcodebuild clean, but this fails since custom build directories are set. The current workaround is to have to trash the entire CMake build folder. With many subprojects this then takes a long time to rebuild. Can Apple please fix this?
Here I have a project with multiple targets (a fake workspace). CMake can only generate xcprojects and not xcworkspace files. Visual Studio and Android Studio both integrate CMake into the IDE. But building iOS and macOS universal apps is still not simple with CMake. Can Xcode team support CMake better in general?
cmake --build . --target clean
xcodebuild -project foo.xcodeproj clean -target ALL_BUILD -parallelizeTargets -configuration Debug -hideShellScriptEnvironment
Command line invocation:
xcodebuild -project foo.xcodeproj clean -target ALL_BUILD -parallelizeTargets -configuration Debug -hideShellScriptEnvironment
User defaults from command line:
HideShellScriptEnvironment = YES
note: Using new build system
note: Building targets in parallel
error: Could not delete `build/lib` because it was not created by the build system.
error: Could not delete `build/app1` because it was not created by the build system.
error: Could not delete `build/app2` because it was not created by the build system.
warning: Refusing to delete `build` because it contains one of the projects in this workspace: `build/foo.xcodeproj`.
CLEAN FAILED
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
This seems to defeat the purpose of a developer forum, if no one can respond to posts except for Apple. Some of my posts are less than 1 month old? Even I don't check the forums that often, but it would be nice to respond to people's questions that have accumulated.
The macOS screen recording tool doesn't appear to support recording HDR content (f.e. in QuickTime player). This tool can record from the camera using various YCbCr 422 and 420 formats needed for HVEC and ProRes HDR10 recording, but doesn't offer any options for screen recording HDR.
So that leaves in-game screen recording with AVFoundation. Without any YCbCr formats exposed in Metal api, how do we use CVPixelBuffer with Metal, and then send these formats off to the video codes directly? Can we send Rec2020 RGB10A2Unorm data directly? I'd like the fewest conversions possible.
The Adobe C++ plugin SDK are still using Rez to compile resources on macOS and winOS. But Rez build settings are missing from my newly created project. They exist in a legacy project. How does one re-enable this functionality. I don't know that Apple has offered an alternative to file-based resource generation, so removing this functionality seems premature.
The help and man pages on Rez are missing a lot. What to supply for arch (x86_64)? Why do I have to supply the framework path to Xcode to find Carbon.r and CoreServices.r? Rez itself provides only the barest of command line usage details.
For example, I couldn't get .r includes to work with -i or -s, but it works with -I. But the resulting .rsrc file that is generated by my command line efforts is 0 sized. The one built from Xcode is 1.5KB (correct).
Also SIP was blocking all attempts to debug these plugins, but a workaround was found for that.
To minimize uptime, I am currently using two command buffers. One holds offscreen commands and is then committed. Then the second waits 20-30ms under heavy gpu use on nextDrawable, does a little work, and calls presentDrawable(which is drawable.present in addScheduledHandler).
This whole setup seems less than ideal. On Android, Vulkan stalls very little on vkImageAquire, and mostly on vkQueuePresent, but that is after the command buffer is ended and submitted. Doing that present call on a thread is often suggested, but the command buffer is already complete and submitted to the gpu before that call.
Metal stalls the commit of the command buffer from this fundamental architecture limitation. I would prefer to have a single command buffer here. The nextDrawable especially with frontBufferOnly set is really just a reference to a drawable, and shouldn't lead to such a long stall. This also makes using double buffering nearly impossible.
For as long as I've used Xcode, the Issue navigator shows stale errors and warnings even after the build is completely building and executing. It would be nice to have a way to retain file warnings without having to set "warnings as errors", but here the problems have already been fixed.
Also need a "Reveal in Report Navigator" since half the time these errors/warnings lack 90% of the info needed to actually fix them. There's already a "Reveal in Project Navigator" that is almost never needed.
Not sure why this has to be so obscure. But somehow adding the call into toggleFullscreen, even though this appDelegate doesn't have a window set, adds a menu item with the fn+F menu item. Posting this to save other pain. Plus the View menu doesn't even have a reference, and is empty otherwise. Pretty hard to polish something shippable with these unfixed outstanding flaws in the API.
CommandGroup(after: .toolbar) {
// must call through NSWindow
Button("See Below") {
// Window isn't set in AppDelegate, so menu item is skipped.
// But add fn+F menu item into app. Suo many stupid hacks.
appDelegate.window?.toggleFullScreen(nil)
}
}
Xcode 16 breaks fundamental feature of error/warning clickthrough to a given header or .cpp file. The issues list will jump to the point of include, instead of the actual error/warning. There's not even a highlighted line since these files aren't the source of the error.
Not really sure how this one got through QA since Apple uses Xcode internally. Now I'm constantly having to scour the report navigator, open the items, and then manually jump to file/line.
There's nowhere to add -mf16c and -mfma that doesn't cause a uinversal build to spew warnings about those settings when it builds arm64. I'd rather not have to add a xcconfig file across every project with an x64 specific setting. So why doesn't the AVX2 setting (-mavx2) also set these flags?
-mhaswell does, and so does -mx86-64-...-v3, but those seem to only be supported by clang-cli on Windows.
I typically read an extended gamepad capture() and get all state. But PSVR2 controllers seem to report nothing. So the stick and other buttons don't do anything in a built app. They register as left/right controllers. This on vOS 26, Xcode 26, etc.
They work correctly in the main icon view, although they don't honor inverted vertical and horiztonal scrolling. Both of the default scrolls just feel wrong. When I move left I'm want to scroll level not right. Same for up/down.
I was working on a macOS ObjC++ tool that allocated and then replaced a single MTLTexture, and noted that all of the textures were leaked. This project was built with CMake, and I found out the Xcode defaults ARC to off.
ARC has been around long enough that I can't think of many ObjC or Swift projects that would work without it. This default should probably be changed.
The workaround for now, is in all CMakeLists.txt files, to set the following:
XCODE_ATTRIBUTE_CLANG_ENABLE_OBJC_ARC YES
When you use the simd classes like float3/matrix3x3 on Swift they are great. I can write and run code like this from existing math routines that are readily found on the web.
let value = m[0][0] * v[0]
When you try to do this in C++/ObjC, the code becomes this. This is not code readily found on the web, and is a big pain to convert.
float value = m.columns[0][0] * v[0];
Can the float3x3 and other wrappers to simd_float3x3 provide an operator[] to the column and other operations like splatting since v[0] above pulls the data out of simd registers.
We currently have to derive off the matrix classes, but it seems like functionality that should be provided in the C/C++ simd classes. A vector math library should promote better code readability than this. We seem to not be able to derive off the vector types which is an issue below.
I also have code based on classes that takes 3 elements that suddenly has to convert to this less readble form.
float3 v(x,y,z) - float3 v(simd_make_float3(x,y,z))
And then there's this code that should fill all values like init repeating in Swift. This is error prone in converting existing simd code to Accelerate simd. So then we try to wrap the float3, can't derive off them, and then lose all swizzling support, operators, etc. Then have to roll our own ops on that struct that holds a float3. What's the recommended way to make this more C++ like without more compiler support
float3 v = {3} - 3,0,0 wasn't expecting that
float3 v(3) doesn't compile
v = {3,0,0} is completely different syntax, and doesn't line up with MSL and most simd libraries
struct myfloat3 : float3 doesn't work
struct myfloat3
{
float3 v; - works, but loses swizzles, operators, etc
explicit myfloat3(float value)
myfloat3(float x, float y, float z)
...
}
The problem with ClampToEdge is that it stretches the outer strip of pixels even when uv goes outside [0,1]. So the typcial change is to use ClampToZero.
The problem with ClampToZero/Border of 0 is that it pulls in black transparent color into images. What would be better is for this to double up the edge pixels of the texture (ClampToEdge), and only once uv exceeds 0,1 then bilerp the transparent color. Currently ClampToZero pulls in black and drops alpha at the edges of small images leading to poor edges of small textures.
Bad Message 431
reason: Request Header Fields Too Large
That's the result I get trying click on any forum message from Google Chrome. Safari doesn't exhibit this issue, so please fix the html that drives for forums so that more browsers are supported.
So I'm trying to maintain free open-source macOS tools. These two tools are sandboxed and hardened runtime. One is an image viewer that writes out a perftrace file into the sandbox folder (in Containers). Then another app tries to open that perftrace file (json).
When the perftrace file is opened in Xcode (signed and notarized), the file opens fine the first and all subsequent times.
When the opening app is kram-profile (signed not notaraized), the file opens once and then nothing can ever open it again. The app has attribute com.apple.quarantine set on it.
The only workaround to then open this file is to remove the attribute
xattr -d com.apple.quarantine <filename>
This is my tool build in Xcode, and having to sign let alone notarize an app is a large amount of complexity. Also this app is available on github.
Topic:
Code Signing
SubTopic:
Notarization