## digitalmars.D.ide - dub root folder as environment-variable in VisualD

• ShadoLight (35/35) Jan 03 I switch frequently between creating + building projects in dub,
• ShadoLight (12/15) Jan 03 At the moment I can make this work by creating a system/user
• Rainer Schuetze (5/24) Jan 04 AFAICT dub generates the VS solution in the same folder as your root
• ShadoLight (36/62) Jan 04 Hi Rainer, thanks for the reply but, no, that is actually what I
• Rainer Schuetze (8/42) Jan 05 Indeed I misunderstood. These paths are generated by dub, so it's mostly
• ShadoLight (9/17) Jan 06 On Wednesday, 6 January 2021 at 07:39:18 UTC, Rainer Schuetze
I switch frequently between creating + building projects in dub,
and then switching to VisualD if debugging is required. dub
excels at dependency management and VS+VisualD excels at
debugging... so this works as a nice work-flow for me.

I generate the VisualD solution with dub and dub does an
admirable job of including all the dependencies as required
(although there are some minor shortcomings... but nothing
serious, so lets ignore those).

But, if you have a number of dependencies, you can end up with a
dependencies in VisualD, all looking like this:

"C:\Users\someBloke\AppData\Local\dub\packages\some\path\to\dep1\..."
"C:\Users\someBloke\AppData\Local\dub\packages\some\path\to\dep2\..."
..etc..

This is as a consequence of dub (on Windows) installing all
packages to "C:\Users\someBloke\AppData\Local\dub\...etc..".

I don't particularly like this (I would prefer to be able to
specify the root folder for dub packages), but it would already
be an improvement if you could use an environment variable to
refer to the root of dub packages in your VisualD project
properties, so that instead you could have the following on the
VisualD side:

"$(DUB_PACKAGES_ROOT)some\path\to\dep1\..." "$(DUB_PACKAGES_ROOT)some\path\to\dep2\..."
..etc..

I tried a couple of "work-arounds" using the global "Import
Paths" under "VisualD Settings", but cannot avoid having to
specify the full paths.

dub defines a number of environment-variables [1], but it looks
like the dub ones are expanded when dub generates the
*.visualdproj project (the VisualD+VS ones are not).

Is there some way this can be done at the moment? (modulo some
trickery using external *.bat files or system
environment-variables)

[1] https://dub.pm/package-format-json.html#environment-variables

Jan 03
On Sunday, 3 January 2021 at 22:21:54 UTC, ShadoLight wrote:
[..]
Is there some way this can be done at the moment? (modulo some
trickery using external *.bat files or system
environment-variables)

At the moment I can make this work by creating a system/user
environment-variable for this, but this still means I need to
modify (typically multiple paths in the VisualD project each time
I generate a VisualD project with dub.

(Well, you obviously also have to do this if you manually create
a VisualD project inside VS that has dependencies - but then at
least you expect to do this since you are doing everything
manually).

I'm interested if there is currently a way to do this via dub..?
or VisualD?

Jan 03
Rainer Schuetze <r.sagitario gmx.de> writes:
On 03/01/2021 23:40, ShadoLight wrote:
On Sunday, 3 January 2021 at 22:21:54 UTC, ShadoLight wrote:
[..]
Is there some way this can be done at the moment? (modulo some
trickery using external *.bat files or system environment-variables)

At the moment I can make this work by creating a system/user
environment-variable for this, but this still means I need to modify
(typically multiple paths in the VisualD project each time I generate a
VisualD project with dub.

(Well, you obviously also have to do this if you manually create a
VisualD project inside VS that has dependencies - but then at least you
expect to do this since you are doing everything manually).

I'm interested if there is currently a way to do this via dub..? or
VisualD?

AFAICT dub generates the VS solution in the same folder as your root
project. So maybe you can use $(SOLUTIONPATH) as a replacement in the generated visuald project. See https://rainers.github.io/visuald/visuald/ProjectConfig.html  Jan 04 ShadoLight <ettienne.gilbert gmail.com> writes: On Monday, 4 January 2021 at 20:40:37 UTC, Rainer Schuetze wrote: On 03/01/2021 23:40, ShadoLight wrote: On Sunday, 3 January 2021 at 22:21:54 UTC, ShadoLight wrote: [..] Is there some way this can be done at the moment? (modulo some trickery using external *.bat files or system environment-variables) At the moment I can make this work by creating a system/user environment-variable for this, but this still means I need to modify (typically multiple paths in the VisualD project each time I generate a VisualD project with dub. (Well, you obviously also have to do this if you manually create a VisualD project inside VS that has dependencies - but then at least you expect to do this since you are doing everything manually). I'm interested if there is currently a way to do this via dub..? or VisualD? AFAICT dub generates the VS solution in the same folder as your root project. So maybe you can use$(SOLUTIONPATH) as a
replacement in the generated visuald project. See
https://rainers.github.io/visuald/visuald/ProjectConfig.html

Hi Rainer, thanks for the reply but, no, that is actually what I
had in mind. It is not a "macro replacement" variable to the path
to the generated visuald project, it is a "macro" variable (i.e.
it would be something like $(DUBROOTPATH)) usable in VisualD's Project Properties for any paths to dub packages that the generated visuald project depends on ("Additional Import Paths"/"String Import Paths"/"Library Files"/etc) My issue is really just the verbose-ness of paths to dub packages ... they are all quite long and, since they all share the same path to the dub root of all packages i.e... "C:\Users\userName\AppData\Local\dub\packages\some\path\to\dep1\..." "C:\Users\userName\AppData\Local\dub\packages\some\path\to\dep2\..." ..it would just be nice to be able to be able to shorten this to... "$(DUBROOTPATH)some\path\to\dep1\..."
"$(DUBROOTPATH)some\path\to\dep2\..." It would also be a bit more flexible to switch the$() macro to
point to a local (modified) version of a package, for example.

I thought I could instead use
"$(APPDATA)dub\packages\some\path\to\dep1\..." as an acceptable alternative (I found some dub forum post that claimed that is what dub uses on windows), but it does not work - my APPDATA points to "..\AppData\Roaming\..", whilst dub used "..\AppData\Local\..." for packages in my case. I know APPDATA can be defined differently (Roaming vs Local) according to whether your computer is part of a domain or something (mine is), but in my case dub did not seem to use the APPDATA variable as mine is defined, so I've had to add my own user variable to resolve this. I figure it would have been nice to be able to use the same system environment variables dub uses to access the packages, as that will make it easier to update dub to use the system variables, rather than the full paths, when it generates the visuald project. But this id really not very important.  Jan 04 Rainer Schuetze <r.sagitario gmx.de> writes: On 05/01/2021 00:43, ShadoLight wrote: My issue is really just the verbose-ness of paths to dub packages ... they are all quite long and, since they all share the same path to the dub root of all packages i.e... "C:\Users\userName\AppData\Local\dub\packages\some\path\to\dep1\..." "C:\Users\userName\AppData\Local\dub\packages\some\path\to\dep2\..." ..it would just be nice to be able to be able to shorten this to... "$(DUBROOTPATH)some\path\to\dep1\..."
"$(DUBROOTPATH)some\path\to\dep2\..." Indeed I misunderstood. These paths are generated by dub, so it's mostly dub that has to be changed to use some environment variable. It would also be a bit more flexible to switch the$() macro to point to
a local (modified) version of a package, for example.

I thought I could instead use
"\$(APPDATA)dub\packages\some\path\to\dep1\..." as an acceptable
alternative (I found some dub forum post that claimed that is what dub
uses on windows), but it does not work - my APPDATA points to
"..\AppData\Roaming\..", whilst dub used "..\AppData\Local\..." for
packages in my case.

I know APPDATA can be defined differently (Roaming vs Local) according
to whether your computer is part of a domain or something (mine is), but
in my case dub did not seem to use the APPDATA variable as mine is
defined, so I've had to add my own user variable to resolve this.

LOCALAPPDATA is probably what you are looking for. Only if it is not
set, dub uses APPDATA.

I figure it would have been nice to be able to use the same system
environment variables dub uses to access the packages, as that will make
it easier to update dub to use the system variables, rather than the
full paths, when it generates the visuald project.

But this id really not very important.

There is also the option to "Add import paths of project dependencies"
which might help to remove most of the paths from the setting. That
option didn't exist when "dub generate" was implemented, though.

Jan 05
On Wednesday, 6 January 2021 at 07:39:18 UTC, Rainer Schuetze
wrote:

[..]
These paths are generated by dub, so it's mostly dub that has
to be changed to use some environment variable.

Indeed. There are a few things in dub that should be improved for
visuald <-> dub to complement each other nicely. It is on my
"to-do" list, if I can only find the time (and motivation!)

[..]
LOCALAPPDATA is probably what you are looking for. Only if it
is not set, dub uses APPDATA.

Oh wow! I must have been blind...

There is also the option to "Add import paths of project
dependencies" which might help to remove most of the paths from
the setting. That option didn't exist when "dub generate" was
implemented, though.

Another thing for that 'dub generate' improvement.

Jan 06