> 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].
Iain
