On 11 Nov 2023, at 18:10, Iain Sandoe <idsan...@googlemail.com> wrote: > >> On 11 Nov 2023, at 07:47, Simon Wright <si...@pushface.org> wrote: >> >> On 6 Nov 2023, at 08:36, Arnaud Charlet <char...@adacore.com> 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).
