Make `digger install` more linux-friendly

[mihails-strasuns]

Currently digger install can't work with system-wide installation of dmd by design - checking PATH will find a /usr/bin/dmd which user has no write access to (fortunately :)). So it pretty much forces developer to setup some non-standard system setup manually which is a Bad Thing (TM).

I'd personally prefer digger install to prepare portable distribution in a folder defined by digger.ini with a -dev suffix appended to binaries (also defined by digger.ini). Though any other option that won't require developer tinkering with the system will be good too.

[CyberShadow]

By design digger install can only upgrade existing installations, because it does not build all files that exist in a common DMD installation.

To upgrade a system-wide installation under Linux, simply run Digger as root.

If you want a full installation in your home directory that's upgradable by Digger, you can use DVM.

If you don't want a full installation of DMD, simply copy the result directory anywhere you like.

[mihails-strasuns]

I don't want to upgrade system-wide installation (there is package manager for that). I wanted to be able to have both system-wide installation and user-local development one. You think this is out of scope for digger?

[CyberShadow]

there is package manager for that

A package manager can't install a customized version of D.

You think this is out of scope for digger?

The result directory that Digger creates is portable, so technically speaking, if you don't need the additional components, Digger already can do this. Just use mv or cp -r as your "install" command.

In the future, Digger may learn to build additional D components (the additional import libraries, all the tools, the documentation, etc.). But this is orthogonal to the above.

[mihails-strasuns]

Ok, let's close as invalid in that case. I will look intro distributing accompanying shell script for copying / path manipulation instead.

[mihails-strasuns]

Alternatively I could try maintaing local set of patches on top that make it more integrated with the system package manager (i.e. digger install building a package and forwarding to pacman -U but I don't know if you would be comfortable with such deviation from the upstream.

[CyberShadow]

I don't mind at all as long as it's called differently (I don't want to guess which "digger install" users are having trouble with) and you can do support in case any issues arise and are reported.

[CyberShadow]

Actually it doesn't need to be a local patch, I'll accept a pull request implementing install-pacman OSLT.

[CyberShadow]

Note that digger install can take a path to dmd as a parameter. So a way to implement this would be to unpack the official DMD tarball, run digger install on top of that, then package the result.

Since it's been a year now, I'm guessing this is no longer needed / relevant, but let me know if I should reopen.

[mihails-strasuns]

Fine by me. It would still be needed if I wanted to put digger package in main Arch repos, but there doesn't seem to be any demand for that and I can hack whatever is needed locally for myself.

[CyberShadow]

I'm still not exactly certain of what specifically is needed. What's the action plan here? Other than making Digger build a full package like what's in the dlang.org tarballs, that's outside of its scope.

[mihails-strasuns]

I think with a way to configure different naming scheme (to not clash with system-wide dmdinstall) rest can be done as part of packaging process (make a user-local dmd installation under a different name and bing digger to it). But it is very low priority topic.

[CyberShadow]

I think with a way to configure different naming scheme (to not clash with system-wide dmdinstall)

So the goal is to install into /usr/bin etc. but not clash with system installations?

You may find that to be difficult...

• dmd will always look for /etc/dmd.conf unless -conf= is specified (or a file is found in the home/local directory etc.)
• rdmd will invoke dmd by default
• dmd will link with libphobos2.a by default
• Phobos' std directory needs to be named std
• Probably more...

It would probably be easier to create wrappers which exec a dmd in another directory. If you place a dmd.conf in the same directory as the dmd binary, it will take precedence over /etc/dmd.conf.

What is the final goal (final end-user workflow) you're trying to accomplish?

[mihails-strasuns]

So the goal is to install into /usr/bin etc. but not clash with system installations?

No, the goal is to install in ~/.cache/digger/ (or similar, I need to check FHS guidelines for that) for D development / debugging but without clashing with system-wide install (for actually using D). To write to /usr/bin one needs root access, that would be out of question for packaged user land program.

dmd will always look for /etc/dmd.conf

Has it changed? I have been successfully using setup before with custom dmd.conf located in the same folder as dmd binary and it took priority over global /etc/dmd.conf. It allowed to to specify different path to -defaultlib too, as well as different standard include path for Phobos.

[CyberShadow]

that would be out of question for packaged user land program

I still only have a very vague understanding of your end goal.

Has it changed? I have been successfully using setup before with custom dmd.conf located in the same folder as dmd binary and it took priority over global /etc/dmd.conf.

No, that will still work.

[mihails-strasuns]

I still only have a very vague understanding of your end goal.

To sum it shortly - to be able to do pacman -S digger once and keep using it from there without any root access required and without creating any files not controlled by package manager.

[mihails-strasuns]

(and also for whatever digger does to never affect installation of dmd from pacman -S dmd in any way)