Hello Simon, Arno, > On 17 Nov 2023, at 13:43, Simon Wright <si...@pushface.org> wrote: > >> >>> Apple’s naming is definitely confusing in this area! >>> >>> In current SDKs, TARGET_OS_MAC means code is being generated for a Mac OS X >>> variant, >>> which covers OSX, IOS, Watch … ; to determine which kind of device, you >>> have to check the >>> specific define for that device - OSX corresponds to macOS, i.e. laptops, >>> desktops. >>> >>> In older SDKs (specifically Xcode 3, for macOS Leopard (darwin 9) as >>> mentioned by Iain) >>> TARGET_OS_MAC means code is being generated for "Mac OS", i.e. laptops, >>> desktops as >>> above; TARGET_OS_OSX is undefined (as are TARGET_OS_IOS etc). >>> >>> If we are compiling for macOS, using a current macOS SDK, then >>> TARGET_OS_MAC is >>> set to 1 and TARGET_OS_OSX is set to 1. >>> >>> If we were compiling for iOS, using a current iOS SDK as supplied with >>> current Xcode, then >>> TARGET_OS_MAC would be set to 1, TARGET_OS_OSX would be set to 0, and >>> TARGET_OS_IOS would be set to 1. >> >> OK so then the following is sufficient for our needs: >> >> #elif defined (__APPLE__) >> /* By default, macOS volumes are case-insensitive, iOS >> volumes are case-sensitive. */ >> #if TARGET_OS_IOS >> file_names_case_sensitive_cache = 1; >> #else >> file_names_case_sensitive_cache = 0; >> #endif >> #else /* Neither Windows nor Apple. */ >> file_names_case_sensitive_cache = 1; >> #endif >> >> We want the default to be 0, and we only care about setting it to 1 on iOS >> for recent >> SDKs, the case of an old SDK and iOS isn't interesting at this stage, so >> it's fine if we set >> the var to 0 in this scenario. > > I can’t speak for Darwin maintainers, so I’ll leave it to Iain to comment on > this suggestion.
* We are far away from having support for watchOS (32b Arm64) so I think that is a bridge that can be crossed later. * It seems to me that the proposed solution is better matched to the defaults on macOS/iOS. * It would be better to have an automatic solution for folks (like me) who do use case- sensitive file systems on macOS, but we do not have the resources right now to figure out what is not working on the earlier systems. I looked briefly, and found that the libcalls are thin wrappers on a syscall, so that the different behaviours we are seeing on earlier OS versions reflects the kernel’s handling of the provided path, rather than some improvement in newer library functions. That suggests to me that we will need to wrap the call in some more complex logic to obtain the correct response. So, I think that (with a test across the range of supported OS versions) the proposed solution is an incremental improvement and we should take it. When there’s a final proposed patch, I can add it into my testing across the systems. Iain
