www.digitalmars.com         C & C++   DMDScript  

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

reply ShadoLight <ettienne.gilbert gmail.com> writes:
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 
substantial number of "Additional Import Paths" for your 
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 2021
parent reply ShadoLight <ettienne.gilbert gmail.com> writes:
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 2021
parent reply 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 2021
parent reply 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 2021
parent reply 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 2021
parent ShadoLight <ettienne.gilbert gmail.com> writes:
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 2021