https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87488
Egmont Koblinger <egmont at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |egmont at gmail dot com
--- Comment #12 from Egmont Koblinger <egmont at gmail dot com> ---
(In reply to Jonathan Wakely from comment #3)
> [the spec] says there should be a hostname part, so not just
> file:///path but file://hostname/path
Yes. The exact reason for this design is that it can be detected when the
filename belongs to a remote host and not mistakenly open its local
counterpart.
E.g. gnome-terminal just tells you it doesn't know how to open that file.
iTerm2, as far as I know, offers you to fetch it via scp (which only works if
the host is accessible under its name in a single hop).
> If I compile on a remote machine I don't want URLs that include the remote
> hostname (which might not even be reachable from my local machine via that
> name) or even necessarily the path relative to the remote machine.
Do you have any particular concern other than "I don't want..."?
You access a remote host from your local one (possibly via multiple hops) and
you're free to issue commands like "hostname" remotely. It's most likely
printed in your prompt. I don't see how the remote host automatically telling
it when you run gcc would be any sort of data leakage or privacy concern -- if
that's what you are worried of.
> I might
> want to be able to click on a filename in the output of the remote
> compilation but have it open the corresponding file locally.
Fair expectation from the user's point of view. iTerm2's scp feature does this
in simple setups.
> So it might be
> useful to have one or more -fdiagnostic-xxx options that allow me to set the
> hostname explicitly,
Or gcc could simply prefer $HOSTNAME if defined.
> and/or to map from one path to another. So when I click
> on myfile.c on the remote host I can get a URL to a local copy of that file
> (which I would edit and push to the remote machine before recompiling).
It's unclear to me how that local copy would be created -- or do you only
consider setups where the entire source tree has a local copy available? And
what about files that are outside of your project, e.g. system headers? If gcc
wants to point to /usr/include/stdio.h of the remote host, how would it map to
a local one?
That being said, I'm not against this approach at all. Maybe you could define
how your remote files map to local ones, and ones that don't have a 1:1 local
counterpart (with guaranteed same content) would remain unlinkified by gcc. Or
maybe you could rewrite all filenames so that they use sshfs that lets you
access the entire remote filesystem. Seems perhaps a bit cumbersome to
implement, and also potentially cumbersome for users to set up, and your use
case might IMHO be a quite special one, so I'm not sure if it's all worth it,
but it might be.
I assume however that the majority of developers compile locally. (Do you gcc
devs have any stats on this?) For them linkifying the files would just work,
and might be a great convenience feature. IMO a convenience feature not working
for all of gcc's users, only for the majority of them, should not be a reason
per se for rejecting it.
And let me emphasize again: Those who compile remotely wouldn't get a sneaky
faulty behavior where a different local counterpart is opened and they waste
precious time pondering why the hell that's relevant at all (assuming that the
remote hostname differs from the local one, a pretty reasonable assumption I
hope). The worst they would get is a hyperlink that fails to open. GCC could
even employ other simple low hanging fruit tricks, e.g. to enable/disable
linkifying filenames by default based on the absence/presence of some $SSH_*
env var or so, or the build system could do such magic.
(In reply to David Malcolm from comment #4)
> Is there a way to encode the line number in the URL?
Unfortunately no, not yet. See the comments under the gist (especially the ones
from Aug 2019) for the reasons and where we are stuck at the moment.
