Bug 4567 – dmd should print the dmd.conf location with usage statement

Status
RESOLVED
Resolution
FIXED
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
Other
OS
All
Creation time
2010-08-01T17:45:00Z
Last change time
2015-02-18T03:39:10Z
Keywords
pull
Assigned to
nobody
Creator
jyasskin

Comments

Comment #0 by jyasskin — 2010-08-01T17:45:47Z
I accidentally had a dmd.conf sitting in my ~/tmp directory, which produced this really confusing interaction: ~/src$ /usr/local/bin/dmd d-grep/main.d -ofgrep -w -wi -g d-grep/main.d(2): Error: module blah is in file 'blah.d' which cannot be read import path[0] = /usr/local/bin/../share/dmd2/phobos import path[1] = /usr/local/bin/../share/dmd2/druntime/import ~/src$ cd ~/tmp ~/tmp$ /usr/local/bin/dmd ~/src/d-grep/main.d -ofgrep -w -wi -g object.d: Error: module object is in file 'object.d' which cannot be read import path[0] = ./../share/dmd2/phobos import path[1] = ./../share/dmd2/druntime/import If dmd had printed that it was using different dmd.conf files for each run, I'd have found the problem much faster.
Comment #1 by hsteoh — 2014-11-01T15:43:08Z
Running dmd -v does print out which config file it's using. Would that be good enough?
Comment #2 by schveiguy — 2014-11-03T16:19:34Z
(In reply to hsteoh from comment #1) > Running dmd -v does print out which config file it's using. Would that be > good enough? Yes, this bug is really old, it's possible it didn't back then.
Comment #3 by schveiguy — 2014-11-03T16:41:33Z
Hm... on second thought, dmd -v spits out a LOT of stuff. I don't want to contend with that when looking for that one piece of info. It would be nice for dmd *without* any parameters to spit out the config location. Even if dmd -v did it (without any other parameters), it would be good. But I think asking for env variables is a bit too much. Updating bug and reopening.
Comment #4 by hsteoh — 2014-11-03T23:24:34Z
Running dmd without any input files spits out a long usage screen dump. Wouldn't the config location get lost in there?
Comment #5 by hsteoh — 2014-11-03T23:38:41Z
Comment #6 by schveiguy — 2014-11-04T02:55:16Z
(In reply to hsteoh from comment #4) > Running dmd without any input files spits out a long usage screen dump. > Wouldn't the config location get lost in there? I built a simple hello world app. dmd -v compiling spit out 141 extremely unreadable lines. dmd without any args spits out 70 lines. But the lines are formatted and organized for easy reading. I'm also frequently used to doing dmd without args to see what version I'm using. dmd.conf naturally belongs there IMO.
Comment #7 by schveiguy — 2014-11-04T02:59:48Z
I like the pull direction -- outputting dmd.conf when object.d cannot be found is a good idea. But it still doesn't solve the issue of when you are compiling with the wrong *working* installation. Is it difficult to add the dmd.conf location to the usage output? Arguably, dmd -v without any parameters should show it.
Comment #8 by hsteoh — 2014-11-04T05:52:47Z
Updated the PR to display the config file along with the usage text, so you can see it if you run dmd with no input files.
Comment #9 by github-bugzilla — 2014-11-04T08:09:13Z
Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e30213d6672bdf7440be662575be2c1cf29b1eb3 Show config file if object.d can't be found. To help troubleshoot problems caused by stray copies of dmd.conf (see bugzilla issue 4567). https://github.com/D-Programming-Language/dmd/commit/96b7b2fdd26fe8b2e4ec8da273d1e2e5c00f6bdc Merge pull request #4108 from quickfur/issue4567 Issue 4567: display dmd.conf path being used if object.d can't be found
Comment #10 by schveiguy — 2014-11-04T15:50:17Z
Nice, thanks!
Comment #11 by github-bugzilla — 2015-02-18T03:39:10Z