rdmd and D equivalent for PYTHONPATH?

Chris Piker chris at hoopjump.com
Thu Mar 18 00:03:52 UTC 2021


On Wednesday, 17 March 2021 at 20:24:19 UTC, Tobias Pankrath 
wrote:

> For scripts this could be a good way, but it does not really 
> work with most dub packages:
>
> 1. put all your dependencies into a single location, like 
> /home/<you>/dstuff
> 2. add -I /home/<you>/dstuff to your call to rdmd/dmd (or put 
> into /etc/dmd.conf
> 3. add -i (lowercase) to your call of rdmd/dmd
> 4. profit

I tried that route, and it's not too bad, but I have C library
dependencies so I start getting shebangs that look like this:

#!/usr/bin/env -S rdmd -i -I${D_PATH} -L-L${LD_LIBRARY_PATH} 
-L-ldas2.3 -L-lexpat -L-lssl -L-lfftw3

So kinda messy, though the rdmd -i option is nice.  Since the dub
packages have the linker info builtin, it seemed better to use 
this
instead:

#!/usr/bin/env dub

and to assist with finding local packages, throw in some sort of
local search path via an environment variable reference in the
dub.sdl section.

If everyone used the same environment variable in dub.sdl comment
it could become a defacto standard for scripts, similar to
PYTHONPATH or MATLABPATH, though not nearly as fundamental.

> To make this work the dependencies must have the correct 
> project layout, e.g. sources should be in the top-level project 
> directory and not in a subdirectory source. This rules out most 
> dub packages :/

Yea, this seemed strange to me.  I'd think that a group would want
the compiler's module lookup semantics to match the common package
layout scheme and vice-versa.  But since I'm new around here I'll
just assume that the mismatch came about for a reason.  The dub
designers were probably trying to solve some problem that I'm 
unaware
of.



More information about the Digitalmars-d-learn mailing list