On 3 Nov 2023, at 08:39, Arnaud Charlet <char...@adacore.com> wrote: > In addition to the non portable issues already mentioned, this change isn't > OK also > for other reasons. > > Basically this function is global and decides once for all on the case > sensitivity, while > the case sensitiviy is on a per filsystem basis as you noted.
Well, the current code does exactly what you describe, with less relationship to the actual environment than this proposal. > 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. > 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. > 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. But anyway, I find myself puzzled by the casing issue. It seems to me that on a CS filesystem users would be well advised to stick to lower-case filenames, or the compiler won’t be able to resolve 'with' statements; whereas on a non-CS system, there’d be no such constraint. Indeed, when compiling a file with a mixed-case name in a CS environment, the compiler warns: $ GNAT_FILE_NAME_CASE_SENSITIVE=1 gcc -c -u -f WTF.adb WTF.adb:1:11: warning: file name does not match unit name, should be "wtf.adb" [enabled by default] Also, there’ve been about 80 downloads of GCC 13.1.0 for aarch64-apple-darwin, and no case-sensitivity issues have been reported. So, Iain, do we want to pursue this? > >> This change affects only Ada. >> >> In gcc/ada/adaint.c(__gnat_get_file_names_case_sensitive), the >> assumption for __APPLE__ is that file names are case-insensitive >> unless __arm__ or __arm64__ are defined, in which case file names >> are declared case-sensitive. >> >> The associated comment is >> "By default, we suppose filesystems aren't case sensitive on >> Windows and Darwin (but they are on arm-darwin)." >> >> This means that on aarch64-apple-darwin, file names are declared >> case-sensitive, which is not normally the case (but users can set >> up case-sensitive volumes). >> >> It's understood that GCC does not currently support iOS/tvOS/watchOS, >> so we assume macOS. >> >> Bootstrapped on x86_64-apple-darwin with languages c,c++,ada and regression >> tested (check-gnat). >> Also, tested with the example from PR ada/81114, extracted into 4 volumes >> (APFS, APFS-case-sensitive, >> HFS, HFS-case-sensitive; the example code built successfully on the >> case-sensitive volumes. >> Setting GNAT_FILE_NAME_CASE_SENSITIVE successfully overrode the choices made >> by the >> new code. >> >> gcc/ada/Changelog: >> >> 2023-10-29 Simon Wright <si...@pushface.org> >> >> PR ada/111909 >> >> * gcc/ada/adaint.c >> (__gnat_get_file_names_case_sensitive): Remove the checks for >> __arm__, __arm64__. >> Split out the check for __APPLE__; remove the checks for __arm__, >> __arm64__, and use getattrlist(2) to determine whether the current >> working directory is on a case-sensitive filesystem. >> >> Signed-off-by: Simon Wright <si...@pushface.org>
