Search dub's own path first to find compiler

[JohanEngelen]

Would it be possible to have the dub executable search its own path first for the compiler? That way, dub will use the compiler it is packaged with. (note: this assumes dub is not on the path, but called e.g. like ~/ldc/ldc2-1.1.0-alpha1-osx-x86_64/bin/dub)

[qznc]

Doing it without path in first argument is harder, but works in most cases: http://stackoverflow.com/q/59895/2361979

[s-ludwig]

There is also thisExePath in Phobos. As mentioned in #303, I'd also like to discuss the alternative to just search for a settings file in the executable directory, in which the "defaultCompiler" field could be set to "./ldc2" or similar.

[JohanEngelen]

I think a settings file would be great, and could be used for many other purposes. It's just more work to implement it ;-)

[s-ludwig]

It's not even really more work. There is a settings file already, it just searches only in /etc/ and ~/.dub now.

[JohanEngelen]

If it is possible to specify the compiler path relative to dub itself, then the config file would work well I think. LDC does something like this: "-I%%ldcbinarypath%%/../import/ldc"
Also, LDC searches ../etc/ before searching /etc/, such that the compiler doesn't have to be installed proper to use it. You can just unpack the LDC package wherever you want.

[s-ludwig]

My idea was that all path entries in the configuration file would be allowed to be relative, and would in that case be treated as relative to the configuration file itself. Using ../etc/ instead of or in addition to the current directory would also be a possibility, although it would be good to keep the rules as simple as possible. I'll open a PR for this (hopefully later today).

[JohanEngelen]

Great thanks a lot!
(we are packaging Dub with the next LDC release, and it'd be great to get this working well with our next release)

[s-ludwig]

PR: #897

[joakim-noah]

This was never actually fixed. Here's the output from trying to run dub on linux/x64 after locally downloading the latest dmd 2.075.0 release, with no dmd in my PATH:

[joakim@localhost ~]$ ./dmd2/linux/bin64/dub run dscanner
Failed to invoke the compiler dmd to determine the build platform: /bin/sh: dmd: command not found

The same with the final ldc 1.3.0 release, no D compiler in my PATH, only the one next to dub:

[joakim@localhost ~]$ ./ldc2-1.3.0-linux-x86_64/bin/dub run dscanner
Failed to invoke the compiler ldc2 to determine the build platform: /bin/sh: ldc2: command not found

All that #897 accomplished was to make ldc use the specified compiler name, in this case ldc2, from the PATH over dmd, it didn't fix the basic problem of not having a D compiler in your PATH. I can put together a pull to remedy this, just as I did for rdmd in dlang/tools#250. I'd check for a compiler next to dub in determineDefaultCompiler first, before trying anything else.

However, I'm unsure what's the intent of specifying the D compiler in a config file at this point. It is only really useful if you know the full path to a D compiler, which any local download won't know, unless the user then modifies or creates a settings.json with that path. System installs, such as in a linux distro, could use it to specify the full path they installed the D compiler at, but that's usually right next to dub anyway. Using a relative path, as suggested above, won't work right now, as it's currently called relative to the directory from which the user invokes dub, ie getcwd, and that will always change.

I can modify the logic to always use the compiler adjacent to dub first, but I wonder if you want that to override settings.json too. Let me know what you want and I can submit a pull.