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