How to correctly deal with dmd.conf with multiple dmd installations - [ref osx, brew, digger]

Vladimir Panteleev thecybershadow.lists at gmail.com
Fri Sep 28 00:11:53 UTC 2018


On Thursday, 27 September 2018 at 19:53:32 UTC, aliak wrote:
> Can you explain a bit maybe how it'd break the maximally 
> reproducible builds with an example? I believe you might've 
> mentioned that in the issue linked but I didn't quite get it.

Well, essentially Digger tries to minimize the number of things 
from its environment that affect the resulting DMD binary, so 
that "digger build <something>" on one machine has the maximal 
chance of producing a DMD binary that is or behaves exactly like 
the result of "digger build <something>" on another machine. 
Fully reproducible builds provide some guarantees which are very 
useful in cases like "this program crashes when built and run on 
machine A but not B", in which case it would allow eliminating 
the possibility of A having a bad compiler (but we aren't there 
with FULLY reproducible builds yet).

Now, some variables like platform or system libraries are 
inevitable, but others, like environment variables or certain 
dependencies, can be controlled. In this case, if we opt in to 
autodetection, a DMD built with the default options on one 
machine with brew won't be the same as a DMD built on a machine 
without brew.

> So let's say dmd in PATH is olddmd and the one we want to build 
> with digger is newdmd.
>
> For the first option, are you suggesting:
> * digger build newdmd
>   1. confFileName = parseFileNameFrom(olddmd -v | grep Config)
>   2. build dmd with SYSCONFDIR=pluckPathFrom(confFileName)
>
> If yes, then that means the newdmd would use olddmd's 
> phobos/lib right?

Well, "digger install" would upgrade Phobos too, but otherwise 
that's the general idea.

> Another idea: create a $HOME/.digger dir at build time. Then 
> digger build could set SYSCONFDIR=$HOME/.digger. And newdmd in 
> work/result/bin/will be fine because there's a dmd.conf near 
> the exe that gets priority.

That's fine until it gets installed systemwide, then problems 
begin.

> digger install (assuming `which dmd` = /usr/local/bin/dmd)
> - if exists(/usr/bin/local/olddmd)
>   move olddmd -> $HOME/.digger/uninstall/ (with whatever else 
> you need)
> - if exists($HOME/dmd.conf)
>   move it to $HOME/.digger/uninstall/ (with metadata saying 
> where it came form)
> - copy newdmd to /usr/bin/local/
> - copy work/result/import to $HOME/.digger/import
> - copy work/result/lib to $HOME/.digger/lib
> - write a new dmd.conf to $HOME/.digger with contents:
> """
> [Environment]
> DFLAGS=-I$HOME/.digger/import -L-L$HOME/.digger/lib
> """

What's the advantage of this over just adding 
digger/work/result/bin to PATH?



More information about the Digitalmars-d mailing list