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

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?

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

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.

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.

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.