Visual D 0.50.0 released

[Rainer Schuetze]

On 26/06/2019 04:35, Bart wrote:
> 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).
> 
> 

You can already find all this information in the output/intermediate
folder, e.g. the dep/lnkdep files are from monitoring compiler and
linker, respectively.

The logs are not as verbose as the ones generated by msbuild, but that
makes them easier to digest.