On 21/02/2014 20:50, H. S. Teoh wrote:
On Fri, Feb 21, 2014 at 08:02:45PM +0100, Johannes Pfau wrote:
Did the old gdmd also parse dmd.conf? I'm not sure if this is
necessary. Parsing /etc/dmd.conf is even problematic as it might
contain library paths with incompatible libraries. We could use a
gdmd.conf but I don't think that's high priority for gdmd? So if that
stuff is already finished - great. If it's not, I wouldn't worry about
that.
The old gdmd did parse dmd.conf
??!!
What was it using from it? A typical dmd.conf would be e.g.
[Environment]
DFLAGS=-I/opt/dmd/include/d2 -L-L/opt/dmd/lib -L--no-warn-search-mismatch
so it's difficult to see what any other compiler/compiler wrapper could get from
that that would be anything other than wrong. Are there options I've previously
been unaware of?
but arguably it should be parsing gdmd.conf instead. I suppose the idea is
that gdmd should be a drop-in replacement for dmd, so if no gdmd.conf is
found, it should probably fall back to parsing dmd.conf?
I don't see why there's a need for any .conf file for gdmd. If each gdmd
install is associated with a unique gdc install (which I think is the correct
choice) then all it needs to do is convert one set of flags to another.
I suppose we could have a .conf file that allows some customization of how that
is done (e.g. that allows you to customize whether -O means -O3 or -O2 or some
other set of optimizations), but it seems overkill.
I can't see any way in which a "fallback to parsing dmd.conf" could have any
positive consequences given what dmd.conf contains.
