public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Arnaud Charlet <charlet@adacore.com>
To: Simon Wright <simon@pushface.org>
Cc: Arnaud Charlet <charlet@adacore.com>,
	gcc-patches@gcc.gnu.org, idsandoe@googlemail.com
Subject: Re: [PATCH] Fix PR ada/111909 On Darwin, determine filesystem case sensitivity at runtime
Date: Mon, 6 Nov 2023 08:36:44 +0000	[thread overview]
Message-ID: <20231106083644.GA2141436@adacore.com> (raw)
In-Reply-To: <6581E8BE-9D03-4F31-B5C4-B9DC79BBE1A7@pushface.org>

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

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

Arno

  parent reply	other threads:[~2023-11-06  8:36 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-29 11:51 Simon Wright
2023-10-31  8:07 ` Iain Sandoe
2023-11-03  8:39 ` Arnaud Charlet
2023-11-04 17:02   ` Simon Wright
2023-11-04 23:28     ` Iain Sandoe
2023-11-06  8:36     ` Arnaud Charlet [this message]
2023-11-11 17:47       ` Simon Wright
2023-11-11 18:10         ` Iain Sandoe
2023-11-13 16:03           ` Simon Wright
2023-11-13 16:18             ` Arnaud Charlet
2023-11-16 20:56               ` Simon Wright
2023-11-17  8:37                 ` Arnaud Charlet
2023-11-17  9:06                   ` Simon Wright
2023-11-17  9:29                     ` Arnaud Charlet
2023-11-17 12:53                       ` Simon Wright
2023-11-17 13:36                         ` Arnaud Charlet
2023-11-17 13:39                           ` Arnaud Charlet
2023-11-17 13:43                           ` Simon Wright
2023-11-21 11:22                             ` Iain Sandoe
2023-11-21 20:25                               ` Simon Wright
2023-11-21 23:13                                 ` Iain Sandoe
2023-11-22 13:54                                   ` Simon Wright
2023-11-22 13:55                                     ` Arnaud Charlet
2023-11-22 14:48                                       ` Iain Sandoe
2023-11-22 15:03                                         ` Iain Sandoe
2023-11-22 15:13                                           ` Simon Wright
2023-11-28 12:16                                             ` Simon Wright
2023-11-28 13:50                                               ` Marc Poulhiès
2023-11-28 16:48                                                 ` Marc Poulhiès
2023-11-22 14:41                                     ` Paul Koning

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231106083644.GA2141436@adacore.com \
    --to=charlet@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=idsandoe@googlemail.com \
    --cc=simon@pushface.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).