Bug 4585 – DMD2 should look for dmd2.conf

If you want to have both dmd1 and dmd2 installed, the fact that both binaries look for the same dmd.conf file is a big complication. It would be nice is dmd2 looked for dmd2.conf instead (or at least look for both, but fist for the dmd2.conf). Naming the binary dmd2 could be nice too, but that can be done by the user, changing what config files to search is not possible.

Better idea: argv[0] ~ ".conf" Then you can have things like: dmd-2.047.conf dmd-2.041.conf etc.

Does argv[0] contain full path to the binary?

(In reply to comment #2) > Does argv[0] contain full path to the binary? No, at least on unix, is the same command you typed, but you can always do basename(argv[0]) and search for that file where the dmd binary (which is already searched by DMD) is, and the other search paths. So I think is a viable option. I find a little odd that the config file changes if you change the binary name, but I can see how it can be pragmatic.

(In reply to comment #3) > (In reply to comment #2) > > Does argv[0] contain full path to the binary? > > No, at least on unix, is the same command you typed, but you can always do > basename(argv[0]) and search for that file where the dmd binary (which is > already searched by DMD) is, and the other search paths. Yes, you can find the path to the binary, or at least the command being run (if its a symlink) by searching the PATH. I think DMD already must do this, because argv[0] is pretty much what's available to find the executable directory in the first place. > So I think is a viable option. I find a little odd that the config file changes > if you change the binary name, but I can see how it can be pragmatic. Often, I have several dmd2 compilers that I want to test because I'm working on bugs in phobos or because I want to know where a regression happened. Currently, I have to specify the full path to the exe, it would be nice to just have them all live in the same directory, and I could then put that dir in my path. So your original solution wouldn't work for this.

(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Does argv[0] contain full path to the binary? > > > > No, at least on unix, is the same command you typed, but you can always do > > basename(argv[0]) and search for that file where the dmd binary (which is > > already searched by DMD) is, and the other search paths. > > Yes, you can find the path to the binary, or at least the command being run (if > its a symlink) by searching the PATH. I think DMD already must do this, > because argv[0] is pretty much what's available to find the executable > directory in the first place. There are system functions to get the path to the currently running executable. I made a function for this to Tango that works on Windows, Linux, Mac OS X and FreeBSD: http://dsource.org/projects/tango/attachment/ticket/1536/process.d . I'm willing to license the code to whatever license necessary for inclusion in dmd. > > So I think is a viable option. I find a little odd that the config file changes > > if you change the binary name, but I can see how it can be pragmatic. > > Often, I have several dmd2 compilers that I want to test because I'm working on > bugs in phobos or because I want to know where a regression happened. > Currently, I have to specify the full path to the exe, it would be nice to just > have them all live in the same directory, and I could then put that dir in my > path. > > So your original solution wouldn't work for this.

(In reply to comment #5) > There are system functions to get the path to the currently running executable. > I made a function for this to Tango that works on Windows, Linux, Mac OS X and > FreeBSD: http://dsource.org/projects/tango/attachment/ticket/1536/process.d . > I'm willing to license the code to whatever license necessary for inclusion in > dmd. Thanks for the offer. But I'd rather not get the exact executable. I used to use symlinks to trick dmd into thinking it was in another directory, I don't want to disable that by having dmd ignore the symlink location. But your offer is generous, and probably would be good to have in phobos. I will keep it in mind! (Phobos' process is due for an update but is blocked by a nasty compiler bug)

You either want them to be in one directory or in different.

Closing this. Please reopen if it's still a pressing issue (but I believe at least in our case we don't have this problem anymore).