On 11 Nov 2023, at 18:10, Iain Sandoe wrote: > >> On 11 Nov 2023, at 07:47, Simon Wright wrote: >> >> On 6 Nov 2023, at 08:36, Arnaud Charlet wrote: >>> >>>>> So without changing fundamentally the model, you can't decide dynamically for the whole >>>>> system. Making the choice based on the current directory is pretty random, since the current >>>>> directory isn't well defined at program's start up and could be pretty much any filesystem. >>>> >>>> I’d imagine that projects spread over more than one differently-case-sensitive filesystem would >>>> be rare. As to the current directory at compiler startup, with GPRbuild it’s the object directory, so >>>> likely to be somewhere near the project’s source tree. >>> >>> I am not talking about the current directory when the compiler runs, I am talking about the >>> current directory where the target program runs, which can be pretty much anywhere. >>> >>> In other words, you are modifying a runtime file (adaint.c) which is used both by the host compiler >>> and by the target applications. My comment worries about the target applications while yours >>> applies to the host compiler only. >> >> I don’t understand? >> >> The change works out whether the filesystem of the current working directory is CS, whether >> it’s the compiler or some user program that’s running it (it looks like that would have to be via >> some higher-level compiler package, I found only GNAT.Command_Line and >> GNAT.Directory_Operations). >> >> I can see that might not be what the user program wants, but if they actually care the current >> situation isn’t great anyway; the compiler definitely makes the wrong choice for new Macs. >> >>>>> Note that the current setting on arm is actually for iOS, which we did support at AdaCore >>>>> at some point (and could revive in the future, who knows). >>>> >>>> Wouldn’t it be more natural to go via LLVM? I understand from Iain that iOS isn’t currently >>>> supported by GCC. >>> >>> That's another option. We'd like to keep both options on the table, since both options have >>> pros and cons. >>> >>>>> So it would be fine to refine the test to differentiate between macOS and embedded iOS and co, >>>>> that would be a better change here. >>>> >>>> There didn’t seem to be a way to do that. >>> >>> OK, I thought there would be some defines that we could use for that, too bad if there isn't >>> and indeed we might need to perform another runtime check then as suggested by Iain. >> >> I can see a possible interface, operatingSystemVersion in NSProcessInfo.h - Objective C >> needed, I think > > Some of the NS interfaces are available to regular C (e.g. stuff in CoreFoundation), and I am > fairly/very sure that we will be able to find a machanism that does not involve introducing an > ObjC dep. [I am obvioulsy not in any way against ObjC - since i’m the maintainer ;) .. but it > seems heavyweight for solving this issue]. It certainly would be heavyweight, since TargetConditionals.h includes TARGET_OS_OSX, which is 1 if we’re compiling for macOS and 0 otherwise (there’s a useful chart at :83 in the MacOSX13.1 SDK). Two ways ahead here: (1) just replace the current __arm__, __arm64__ test with this (2) as 1, but implement the runtime test for case sensitivity only for macOS Whether (2) is acceptable depends, I suppose, on what issues Iain encountered on Darwin 9 & Darwin 17. I’ll be content to go with (1).