On 26 Aug 2017, at 23:31, Thomas Mader via digitalmars-d-ldc wrote:
> The thing with Nix is that every dependency need to be fixed at build time and can't change anymore.
> I was able to find the code where the path to gcc is searched for linking and I just replaced "gcc" with "clang" in driver/tool.cpp.
> Since the CC environment flag is properly set by nix with the full path to clang, it can be found and no gcc is needed at all.

I'm still not sure I understand. Are you saying that Nix purposely doesn't allow the system Xcode installation to be found (which makes sense for a reproducible build system), but doesn't provide a `gcc` symlink in its Clang/Xcode/… package?

Also, if the CC environment variable is set to the path of an executable, LDC should automatically use it already. What the default program is should be inconsequential then.

> I wonder though why there is a special case for FreeBSD in there with clang but not for Mac OSX.

Presumably FreeBSD does not provide a `gcc` symlink by default, unlike Xcode/macOS. You'd have to ask Kai (https://github.com/ldc-developers/ldc/pull/1117) for details, though.

 — David

On 28 Aug 2017, at 9:52, Thomas Mader via digitalmars-d-ldc wrote:
> But I see that it's a problem to directly use clang because without wrapping there might go something wrong.

That won't be an issue, Clang is GCC-compatible for all the commonly used flags by design.

> So with my current knowledge I would suggest that I open a PR to add a condition for OSX with clang too.

I'd suggest looking into why CC isn't automatically picked up first.

 — David

On Monday, 28 August 2017 at 06:19:35 UTC, Jacob Carlborg wrote:
> On 2017-08-27 00:31, Thomas Mader wrote:
>
>> You are right and I probably wouldn't be able to get that merged into upstream this way too.
>> 
>> The thing with Nix is that every dependency need to be fixed at build time and can't change anymore.
>> I was able to find the code where the path to gcc is searched for linking and I just replaced "gcc" with "clang" in driver/tool.cpp.
>> Since the CC environment flag is properly set by nix with the full path to clang, it can be found and no gcc is needed at all.
>
> Can you create a symlink called "gcc" pointing to "clang" and package that? To avoid modifying the source code.

This seems to be an unnecessary redirection and isn't the way such things are handled in Nix AFAIK.
I need to patch sources any way because there are other inpure paths in phobos too.

See the package for dmd for example: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/dmd/default.nix#L44-L65

But I see that it's a problem to directly use clang because without wrapping there might go something wrong.
But if clang wouldn't be supported directly the FreeBSD condition would be wrong too.
So with my current knowledge I would suggest that I open a PR to add a condition for OSX with clang too.

On Monday, 28 August 2017 at 06:19:35 UTC, Jacob Carlborg wrote:
> On 2017-08-27 00:31, Thomas Mader wrote:
>
>> You are right and I probably wouldn't be able to get that merged into upstream this way too.
>> 
>> The thing with Nix is that every dependency need to be fixed at build time and can't change anymore.
>> I was able to find the code where the path to gcc is searched for linking and I just replaced "gcc" with "clang" in driver/tool.cpp.
>> Since the CC environment flag is properly set by nix with the full path to clang, it can be found and no gcc is needed at all.
>
> Can you create a symlink called "gcc" pointing to "clang" and package that? To avoid modifying the source code.

This seems to be an unnecessary redirection and isn't the way such things are handled in Nix AFAIK.
I need to patch sources any way because there are other inpure paths in phobos too.

See the package for dmd for example: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/dmd/default.nix#L44-L65

But I see that it's a problem to directly use clang because without wrapping there might go something wrong.
But if clang wouldn't be supported directly the FreeBSD condition would be wrong too.
So with my current knowledge I would suggest that I open a PR to add a condition for OSX with clang too.

On Monday, 28 August 2017 at 06:19:35 UTC, Jacob Carlborg wrote:
> On 2017-08-27 00:31, Thomas Mader wrote:
>
>> You are right and I probably wouldn't be able to get that merged into upstream this way too.
>> 
>> The thing with Nix is that every dependency need to be fixed at build time and can't change anymore.
>> I was able to find the code where the path to gcc is searched for linking and I just replaced "gcc" with "clang" in driver/tool.cpp.
>> Since the CC environment flag is properly set by nix with the full path to clang, it can be found and no gcc is needed at all.
>
> Can you create a symlink called "gcc" pointing to "clang" and package that? To avoid modifying the source code.

This seems to be an unnecessary redirection and isn't the way such things are handled in Nix AFAIK.
I need to patch sources any way because there are other inpure paths in phobos too.

See the package for dmd for example: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/dmd/default.nix#L44-L65

But I see that it's a problem to directly use clang because without wrapping there might go something wrong.
But if clang wouldn't be supported directly the FreeBSD condition would be wrong too.
So with my current knowledge I would suggest that I open a PR to add a condition for OSX with clang too.

On Monday, 28 August 2017 at 06:19:35 UTC, Jacob Carlborg wrote:
> Can you create a symlink called "gcc" pointing to "clang" and package that? To avoid modifying the source code.

This seems to be an unnecessary redirection and isn't the way such things are handled in Nix AFAIK.
I need to patch sources any way because there are other inpure paths in phobos too.

See the package for dmd for example: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/dmd/default.nix#L44-L65

But I see that it's a problem to directly use clang because without wrapping there might go something wrong.
But if clang wouldn't be supported directly the FreeBSD condition would be wrong too.
So with my current knowledge I would suggest that I open a PR to add a condition for OSX with clang too.

On 28 Aug 2017, at 17:50, Thomas Mader via digitalmars-d-ldc wrote:
> This seems to be an unnecessary redirection and isn't the way such things are handled in Nix AFAIK.
> I need to patch sources any way because there are other inpure paths in phobos too.
>
> See the package for dmd for example: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/dmd/default.nix#L44-L65
>
> But I see that it's a problem to directly use clang because without wrapping there might go something wrong.
> But if clang wouldn't be supported directly the FreeBSD condition would be wrong too.
> So with my current knowledge I would suggest that I open a PR to add a condition for OSX with clang too.

Your email client is either running amok, or you are sending the same two messages over and over again. Either way, please make it stop. Thanks! —David

On Monday, 28 August 2017 at 17:27:46 UTC, David Nadlinger wrote:
> On 28 Aug 2017, at 17:50, Thomas Mader via digitalmars-d-ldc wrote:
>> This seems to be an unnecessary redirection and isn't the way such things are handled in Nix AFAIK.
>> I need to patch sources any way because there are other inpure paths in phobos too.
>>
>> See the package for dmd for example: https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/dmd/default.nix#L44-L65
>>
>> But I see that it's a problem to directly use clang because without wrapping there might go something wrong.
>> But if clang wouldn't be supported directly the FreeBSD condition would be wrong too.
>> So with my current knowledge I would suggest that I open a PR to add a condition for OSX with clang too.
>
> Your email client is either running amok, or you are sending the same two messages over and over again. Either way, please make it stop. Thanks! —David

There was a problem where the forum frontend wasn't posting messages, but then posted them all later.  Happened to me on a different thread, guessing it's what happened here too.

On Monday, 28 August 2017 at 19:17:28 UTC, Joakim wrote:
> There was a problem where the forum frontend wasn't posting messages, but then posted them all later.  Happened to me on a different thread, guessing it's what happened here too.

Exactly

On 28 Aug 2017, at 20:40, Thomas Mader via digitalmars-d-ldc wrote:
> On Monday, 28 August 2017 at 19:17:28 UTC, Joakim wrote:
>> There was a problem where the forum frontend wasn't posting messages, but then posted them all later.  Happened to me on a different thread, guessing it's what happened here too.
>
> Exactly

No worries – just wanted to make sure you are aware of it, since more copies of your original message were coming in, but no replies to my reply. — David