https://github.com/etcimon/windows-headers/issues/9

I got this error, when build with VisualD-v1.0.1-dmd-2.093.1-ldc2-1.23.0.exe

dmd:

Severity Code Description Project File Line Suppression State
Error Deprecati C:\Users...\AppData\Local\dub\packages\windows-headers-1.0.4\windows-headers\source\windows\winnt.d 2759

https://github.com/etcimon/windows-headers/blob/master/source/windows/winnt.d#L2759

```
struct MESSAGE_RESOURCE_DATA {
        DWORD NumberOfBlocks;
        MESSAGE_RESOURCE_BLOCK _Blocks;

        MESSAGE_RESOURCE_BLOCK* Blocks() { return &_Blocks; }  // 2759
}
```

VisualD only shows "Error Deprecati"

how to work-around this issue?

or which older version of DMD does not have this Deprecati(on)? anyone knows?

thanks.

On Monday, 24 August 2020 at 23:39:09 UTC, mw wrote:
> https://github.com/etcimon/windows-headers/issues/9

did you know most windows headers have been included with dmd for a long time now?

Forget those old bindings and instead use the bundled ones.

import windows.winnt;

becomes

import core.sys.windows.winnt;

and then it all just works.

> how to work-around this issue?

you can also use the -d switch to dmd to allow the deprecations but since the bundled headers are all up to date with this that's really what i suggest.

On Monday, 24 August 2020 at 23:45:10 UTC, Adam D. Ruppe wrote:
> On Monday, 24 August 2020 at 23:39:09 UTC, mw wrote:
>> https://github.com/etcimon/windows-headers/issues/9
>
> did you know most windows headers have been included with dmd for a long time now?

I didn't add that package myself, guess it's indirectly pulled in by some other packages.


>> how to work-around this issue?
>
> you can also use the -d switch to dmd to allow the deprecations but since the bundled headers are all up to date with this that's really what i suggest.

I just tried add '-d' as it showed here: in both "Compile+Run" and "Compile+Debug"

https://rainers.github.io/visuald/visuald/GlobalOptions.html

And I did "Rebuild" the solution, but that error still there.

On Monday, 24 August 2020 at 23:57:03 UTC, mw wrote:
> I didn't add that package myself, guess it's indirectly pulled in by some other packages.

oh geeze. you're gonna be in some trouble then since a couple layers of libraries away won't get your build flags. they are compiled independently based on their own configuration.

I'd suggest you use a better library that doesn't have an obsolete dependency. Fork it yourself and update this if there isn't one.

On Tuesday, 25 August 2020 at 00:05:37 UTC, Adam D. Ruppe wrote:
> On Monday, 24 August 2020 at 23:57:03 UTC, mw wrote:
>> I didn't add that package myself, guess it's indirectly pulled in by some other packages.
>
> oh geeze. you're gonna be in some trouble then since a couple layers of libraries away won't get your build flags. they are compiled independently based on their own configuration.

Any easy way to find the offending package?


BTW, I find a work-around (adding "-d" on VisualD doesn't work), I end up add "-d" to the sc.ini file:

$ find /mnt/c/project/dlang/dmd-2.093.1  -name '*ini' | grep bin
/mnt/c/project/dlang/dmd-2.093.1/windows/bin/sc.ini
/mnt/c/project/dlang/dmd-2.093.1/windows/bin64/sc.ini

[Environment]
DFLAGS="-I%@P%\..\..\src\phobos" "-I%@P%\..\..\src\druntime\import" "-d"

Although I'm on 64-bit Windows 10, change bin64/sc.ini does not work; change bin/sc.ini worked.

Hope this will help someone who has similar issues.

On Tuesday, 25 August 2020 at 00:13:40 UTC, mw wrote:
> Any easy way to find the offending package?

idk, you could just search your .dub directory or go down the list of your dependencies and look at their dependencies till it comes up.

(this is one of the reasons why I don't use libraries.)

On Tue, Aug 25, 2020 at 12:55:21AM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Tuesday, 25 August 2020 at 00:13:40 UTC, mw wrote:
> > Any easy way to find the offending package?
> 
> idk, you could just search your .dub directory or go down the list of your dependencies and look at their dependencies till it comes up.
> 
> (this is one of the reasons why I don't use libraries.)

+1. ;-)


T

-- 
Why did the mathematician reinvent the square wheel?  Because he wanted to drive smoothly over an inverted catenary road.

On Tuesday, 25 August 2020 at 02:29:20 UTC, H. S. Teoh wrote:
> On Tue, Aug 25, 2020 at 12:55:21AM +0000, Adam D. Ruppe via Digitalmars-d wrote:
>> 
>> idk, you could just search your .dub directory or go down the list of your dependencies and look at their dependencies till it comes up.
>> 
>> (this is one of the reasons why I don't use libraries.)


Wait, I just read:

https://forum.dlang.org/post/xjjhmclllxrvycpzqtyj@forum.dlang.org

quote:
"""
yup. I have to do this every other week on my work box to keep its hard drive from filling up lol
"""

You don't just use libraries, you use *tons* of them that fill up your hard drive! :-)


>
> +1. ;-)

On Tuesday, 25 August 2020 at 05:21:30 UTC, mw wrote:
> You don't just use libraries, you use *tons* of them that fill up your hard drive! :-)

I'm working on fixing the company's code to get rid of libraries too!

On Tuesday, 25 August 2020 at 00:13:40 UTC, mw wrote:

> Any easy way to find the offending package?

You can run `dub describe` in the root directory of your project. It outputs all information about your project and its dependencies as JSON. For example, it includes all source files. If you use the `jq` command you can easily filter the JSON to exactly what you're looking for. Perhaps something like this:

```
dub describe  | jq '.packages[] | .name, .files'
```

The above command will list all dependencies and their source files.

--
/Jacob Carlborg