August 28, 2017
On Monday, 28 August 2017 at 08:55:22 UTC, David Nadlinger wrote:
> 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?

Exactly, all packages are under /nix/store/ and each package has a different directory in which all files are contained.
The name of the directory starts with a hash which describes the container uniquely and changes each time something in the build description of the package changes or some dependency package changes.

The dependencies are nothing else then the full paths to the container directories in /nix/store

Everything should be pure (work in progress) and so the OS clang package isn't used. Nix needs to provide that on it's own. I opened an issue for it: https://github.com/NixOS/nixpkgs/issues/28647

You are right that if the default system provides the symlink, Nix should too.
But as you said in your later post, ldc works with clang and clang is the default on Darwin, so it seems nicer to just support it that way.

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

If I understood the ldc code correctly (driver/tool.cpp), only gcc is searched for in the environment but not clang. clang is used on FreeBSD only.

August 28, 2017
On 28 Aug 2017, at 21:01, Thomas Mader via digitalmars-d-ldc wrote:
> If I understood the ldc code correctly (driver/tool.cpp), only gcc is searched for in the environment but not clang. clang is used on FreeBSD only.

https://github.com/ldc-developers/ldc/blob/37390e5764494da77a925f8586b2e1187ef08076/driver/tool.cpp#L47-L49

Where would the restriction to `gcc` come in? —David

August 28, 2017
On Monday, 28 August 2017 at 20:09:39 UTC, David Nadlinger wrote:
> Where would the restriction to `gcc` come in? —David

https://github.com/ldc-developers/ldc/blob/37390e5764494da77a925f8586b2e1187ef08076/driver/tool.cpp#L26

and

https://github.com/ldc-developers/ldc/blob/37390e5764494da77a925f8586b2e1187ef08076/driver/tool.cpp#L70

I patched both to get it working for now.
August 28, 2017
On 28 Aug 2017, at 21:13, Thomas Mader via digitalmars-d-ldc wrote:
> https://github.com/ldc-developers/ldc/blob/37390e5764494da77a925f8586b2e1187ef08076/driver/tool.cpp#L26

This is just the name of the command line flag.

> https://github.com/ldc-developers/ldc/blob/37390e5764494da77a925f8586b2e1187ef08076/driver/tool.cpp#L70
>
> I patched both to get it working for now.

None of these should be relevant if CC is set, as per the snippet I linked. Note that the default is only used after the env check. The fact that this doesn't seem to work indicates a bug in that logic, or in the way the environment is set up. What is CC actually set to?

 — David

August 28, 2017
On Monday, 28 August 2017 at 20:18:30 UTC, David Nadlinger wrote:
> None of these should be relevant if CC is set, as per the snippet I linked. Note that the default is only used after the env check. The fact that this doesn't seem to work indicates a bug in that logic, or in the way the environment is set up. What is CC actually set to?

CC is set to the full path to clang (/nix/store/<hash>-<packagename>-<version>/bin)

So it seems that findProgramByName returns empty because it's already a full path. (https://github.com/ldc-developers/ldc/blob/master/driver/tool.cpp#L48)

A check is missing to see if there already is a full path given in CC.
August 28, 2017
On Monday, 28 August 2017 at 20:48:40 UTC, Thomas Mader wrote:
> On Monday, 28 August 2017 at 20:18:30 UTC, David Nadlinger wrote:
>> None of these should be relevant if CC is set, as per the snippet I linked. Note that the default is only used after the env check. The fact that this doesn't seem to work indicates a bug in that logic, or in the way the environment is set up. What is CC actually set to?
>
> CC is set to the full path to clang (/nix/store/<hash>-<packagename>-<version>/bin)

It needs to be set to the binary, not its containing directory. Try adding /clang.
August 28, 2017
On Monday, 28 August 2017 at 20:48:40 UTC, Thomas Mader wrote:
> On Monday, 28 August 2017 at 20:18:30 UTC, David Nadlinger wrote:
>> None of these should be relevant if CC is set, as per the snippet I linked. Note that the default is only used after the env check. The fact that this doesn't seem to work indicates a bug in that logic, or in the way the environment is set up. What is CC actually set to?
>
> CC is set to the full path to clang (/nix/store/<hash>-<packagename>-<version>/bin)

No that might not be the case, normally it's just "clang" I guess. Need to check that tomorrow.
August 28, 2017
On Monday, 28 August 2017 at 20:54:36 UTC, kinke wrote:
> On Monday, 28 August 2017 at 20:48:40 UTC, Thomas Mader wrote:
>> On Monday, 28 August 2017 at 20:18:30 UTC, David Nadlinger wrote:
>>> None of these should be relevant if CC is set, as per the snippet I linked. Note that the default is only used after the env check. The fact that this doesn't seem to work indicates a bug in that logic, or in the way the environment is set up. What is CC actually set to?
>>
>> CC is set to the full path to clang (/nix/store/<hash>-<packagename>-<version>/bin)
>
> It needs to be set to the binary, not its containing directory. Try adding /clang.

Yes I forgot to add the /clang. It's late. ;-)
August 29, 2017
On 2017-08-28 22:01, Thomas Mader wrote:

> But as you said in your later post, ldc works with clang and clang is the default on Darwin, so it seems nicer to just support it that way.

I think it make sense to look for "clang" these days. It's been the system compiler for many years now.

-- 
/Jacob Carlborg
August 29, 2017
On Monday, 28 August 2017 at 20:55:48 UTC, Thomas Mader wrote:
> No that might not be the case, normally it's just "clang" I guess. Need to check that tomorrow.

I just checked. CC is set to "clang" correctly and clang is callable.
Within the PATH variable the path "/nix/store/2dijjcqwnzf0pj1ii524anz55nxm7pjs-clang-wrapper-4.0.1/bin/" is declared and in this directory the clang binary is found.

I guess with this setup "findProgramByName" should find the full path to clang.
Next I will try to build the package without my "gcc" -> "clang" substitution. Maybe it didn't work on some older version of nixpkgs because there was an error.

If it is still not working I need to debug into it more deeply.