Hi Folks > On 4 Nov 2023, at 17:02, Simon Wright <si...@pushface.org> wrote: > > On 3 Nov 2023, at 08:39, 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. It’s likely much less rare to find a CS external disk or an NFS mount, or secondary FS with a non-CS system partition, (since the default for the system install is that way). I am suspicious of second-guessing any of this; my opinion is that if we have an automated recognition of CS, then it needs to work in the general circumstance (that would certainly be in the spirit of macOS “it just works”). If we cannot achieve that, the advantage of the current scenario (GNAT_FILE_NAME_CASE_SENSITIVE=..) is that it is explicit on the part of the user, and therefore puts the onus on the user to get it right. >> 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. Historically, we had no support for Arm or AArch64, so the missing support of iOS as a concept was not important - now we have an AArch64 port, it is feasible and potentially relevant to update this. Having said that, I’m not sure how a a GCC-developed iOS app would be distributed - but of course libraries are a different story. > >> 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. We should be able to do that at runtime (sysctl calls for example) > So, Iain, do we want to pursue this? Right now, I have no spare resources to tackle this, (I suspect that the issues I see on earlier systems are due to the syscall not finding the right root FS from paths like /foo/bar so it remains to be see how to deal with it). I have no objection from a Darwin perspective to folks finding a mutually agreeable solution that works without the user specifying the env. var - but I’m not going to be able to contribute much to the work in the near future. thanks Iain
