Visual D 0.50.0 released

[Bart]

On Tuesday, 25 June 2019 at 19:47:40 UTC, Rainer Schuetze wrote:
>
>
> On 25/06/2019 15:53, a11e99z wrote:
>> On Tuesday, 25 June 2019 at 12:24:03 UTC, a11e99z wrote:
>>> On Sunday, 23 June 2019 at 17:58:27 UTC, Rainer Schuetze 
>>> wrote:
>>>> today a new version of Visual D has been released.
>>>
>>> and now I have some issues with new VD 0.50:
>>> and now main troubles: I cant build any D project any more 
>>> from VS.
>>> - compiling as "LDC x64": again used OPTLINK. why? LDC has 
>>> own lld-link.
>> 
>> I deinstalled Build Tools, installed VC++ from VS-Installer to 
>> Community
>> folder as 99% does.
>> same problems.
>> deinstalled VD0.50, install it again, all settings restored 
>> from olds (I
>> want to do clean installation)
>> deinstalled VD0.50, installed 0.49.2, same problems and same 
>> old settings.
>> pic of LDC x64 w OPTLINK https://pasteboard.co/Il3uc0E.png
>> well, now i can not compile D projects at all with any version 
>> of VD.
>
> "Image not found" for the link.
>
> I suspect that there is something wrong with the order of 
> folders in the PATH environment variable. You can check the 
> generated batch (*.cmd) in the output folder.


Maybe what might help is for VD to output all relevant 
information such as the locations of the compiler, linker, 
library imports, etc... all in an easily one per line file.

I tend to have trouble parsing the logs and such because the 
information is not easily readable unless one knows exactly what 
they are looking for. Specially with large projects.

This may not help with the compiler and linker itself unless you 
were to monitor the file system for changes(like process monitor) 
and then report what it is using but that would be a bit of work.

On my comp LDC does not work and I just get a crash but I don't 
know why. I simply don't use LDC for now.

For example, if you could override all the file commends in VD 
(e.g., if you use std.file you could hijack it) and then output 
all open files to a log along with VD's __FILE__ and __LINE__ 
info to get the source where they are being used at.  Would also 
require doing it with the shell but you basically already do 
it... just maybe pretty print the info so it is more readable. 
E.g.,

VD Options
    ---

Paths:
    Libraries: C:\Lib
    Imports: C:\Imports
    Compiler: C:\dmd\bin

Import libraries:
    C:\libraries\
    D:\foxtrot\tango.m
    ...
<compiler> Command line options:
    -m64
    -g
    -IC:\libraries\
    ...
...

Opened Files:
     C:\project\happy.m <VD: collect.m#34>
     D:\projects\dance.m <VD: import.m#334>
     ....

The point is to be as verbose as possible to provide as much 
contextual information for figuring out problems.



or whatever...


If you setup the framework you could slowly convert everything 
over time by simply logging stuff and as you come across old 
usage you can update it. Maybe get the most relevant first and 
then the rest of the stuff could follow.

There are dll injection libraries that can be used to inject in 
to a process to monitor file system access... could be used on 
the compiler and linker and all the files it uses could be 
stored(the log file would be very large but it would be helpful).