mstorsjo wrote:

> > it makes me wonder if someone actually is relying on the current behaviour
> 
> To rephrase your question, you ask if someone is using a configuration with a 
> folder where various custom libraries are and bin folder with a link to the 
> actual clang, and expects for clang to pick the custom libraries instead of 
> the distributed ones? I obviously can't tell, but I would say that the 
> chances are slim.

To me, it actually sounds entirely possible for someone to want to set up a 
toolchain that way. (I even had a user look into setting up something similar 
to that recently; building user-local installed llvm-mingw toolchains around a 
clang binary provided by a linux distribution.)

> And, in case someone wants such a configuration, the current patch, if 
> `-no-canonical-prefixes` is used, reverts to the previous behaviour, when the 
> symlink is not followed.
> 
> > whatever the consequences are of using a different install dir is kinda of 
> > irrelevant here
> 
> Well, given how much time I spent trying to understand some weird errors 
> caused by this, I would not call them irrelevant :-(

I'm not diminishing your debugging effort - I'm just saying that how annoying 
something was to debug (until you realized that the detected installation dir 
was wrong) doesn't really affect whether clang should change its definition for 
how the install directory is determined. Yes, having it use the wrong install 
directory will of course make things not work as they should.

> > there should be a well defined logic for how that's calculated
> 
> Right, but I would say that the current logic based on the folder where the 
> clang executable is located worked fine till now, and I see no reasons to 
> change it,

With well defined logic, I mean with respect to how symlinks are handled as 
well. Without symlinks involved, the logic for determining the clang install 
directory is near-trivial.

And you make it sound like nobody might have used such symlinks before



https://github.com/llvm/llvm-project/pull/68091
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to