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 > Arno
