Hello

I am trying to build the swdf lib using the supplied makefile, but keep getting this error

K:\sdwf_01a\smjg\libs\sdwf>d:\dm\bin\make -f makefile
dmd -I..\..\.. -O -c windowbase.d
D:\dmd\bin\..\src\phobos\std\c\windows\windows.d(2231): struct BITMAP
conflicts
with winapi.BITMAP at ..\..\..\smjg\libs\winapi.d(51)

--- errorlevel 1

I am using WinXP, has this got anything to do with the error ? The makefile is in this directory

K:\sdwf_01a\smjg\libs\sdwf

and technically I did not need to use d:\dm\bin\make  as it is in my path anyhow

D is in D\dmd\bin
dm is in d\dm

Yeric

Yeric wrote:
> Hello
> 
> I am trying to build the swdf lib using the supplied makefile, but keep
> getting this error
> 
> K:\sdwf_01a\smjg\libs\sdwf>d:\dm\bin\make -f makefile
> dmd -I..\..\.. -O -c windowbase.d
> D:\dmd\bin\..\src\phobos\std\c\windows\windows.d(2231): struct BITMAP
> conflicts
> with winapi.BITMAP at ..\..\..\smjg\libs\winapi.d(51)
> 
> --- errorlevel 1
> 
> I am using WinXP, has this got anything to do with the error ?
> The makefile is in this directory
> 
> K:\sdwf_01a\smjg\libs\sdwf
> 
> and technically I did not need to use d:\dm\bin\make  as it is in my path
> anyhow
> 
> D is in D\dmd\bin
> dm is in d\dm
> 
> Yeric

It's not your fault. And it's not really Stewart's fault either. Walter has an annoying habit of adding things to std.c.windows.windows little-by-little. What compiled perfectly with DMD 0.82 doesn't compile anymore.

You can get it closer to compiling by removing (or commenting out or versioning out) the offending code in SDWF. For example, with your error message from above, go to ..\..\..\smjg\libs\winapi.d and edit line 51. It's probably something like this...
struct BITMAP

If you add a version that's undefined, it won't be compiled anymore...
version(dmd_082) struct BITMAP

Unfortunately, there are probably a couple dozen conflicts like this and at least one other conflict. I stopped with I got stuck (and I don't have my progress with me anyways -- doh!).

Anyways, it's probably not that hard for Stewart to fix, but it's an annoying problem.

-- 
Justin
http://jcc_7.tripod.com/d/

> It's not your fault. And it's not really Stewart's fault either. Walter has an annoying habit of adding things to std.c.windows.windows little-by-little. What compiled perfectly with DMD 0.82 doesn't compile anymore.

Yes it is annoying :) but if it is for the sake of improvement then that is
good :)

Thanks but I think I will await a new build

Yeric

Yeric wrote:
>>It's not your fault. And it's not really Stewart's fault either. Walter
>>has an annoying habit of adding things to std.c.windows.windows
>>little-by-little. What compiled perfectly with DMD 0.82 doesn't compile
>>anymore.
> 
> 
> Yes it is annoying :) but if it is for the sake of improvement then that is
> good :)

Yes, I'm sure he's trying to be helpful.

> Thanks but I think I will await a new build

Yeah, I'll probably wait, too.

> Yeric
> 
> 


-- 
Justin
http://jcc_7.tripod.com/d/

J C Calvarese wrote:

> Yeric wrote:
> 
>> Hello
>>
>> I am trying to build the swdf lib using the supplied makefile, but keep
>> getting this error
<snip>

FTF, it's SDWF, not SWDF.

> It's not your fault. And it's not really Stewart's fault either. Walter has an annoying habit of adding things to std.c.windows.windows little-by-little. What compiled perfectly with DMD 0.82 doesn't compile anymore.
<snip>
> Anyways, it's probably not that hard for Stewart to fix, but it's an annoying problem.

I've just about finished coding up SDWF 0.2, and am working on getting it together ready to release.  It includes an updated winapi module.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

> J C Calvarese wrote:
> 
>> Yeric wrote:
>>
>>> Hello
>>>
>>> I am trying to build the swdf lib using the supplied makefile, but keep
>>> getting this error
> 
> <snip>
> 
> FTF, it's SDWF, not SWDF.
> 
>> It's not your fault. And it's not really Stewart's fault either. Walter has an annoying habit of adding things to std.c.windows.windows little-by-little. What compiled perfectly with DMD 0.82 doesn't compile anymore.
> 
> <snip>
> 
>> Anyways, it's probably not that hard for Stewart to fix, but it's an annoying problem.
> 
> I've just about finished coding up SDWF 0.2, and am working on getting it together ready to release.  It includes an updated winapi module.

Just thinking about it, I'd need to include my fixed std.c.windows.windows module as well, at least if the fix doesn't get into a DMD release in the next few days.  (I think the only reason for keeping a separate smjg.libs.winapi is forward compatibility with Walter's "annoying habit".)

See
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/83

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Sorry about that. One way to protect against such in the future is when you add a declaration to your own modules that really should be in windows.d, qualify it with the name of your module:

    winapi.BITMAP

rather than an unqualified:

    BITMAP

Walter wrote:
> Sorry about that. One way to protect against such in the future is when you
> add a declaration to your own modules that really should be in windows.d,
> qualify it with the name of your module:
> 
>     winapi.BITMAP
> 
> rather than an unqualified:
> 
>     BITMAP 

Actually, it'd be smjg.libs.winapi.BITMAP that way SDWF's modules are set up.

Sound like code-bloat to me.

Apparently, the only way to be phobos-safe with the windows headers is to be independent of std.c.windows.windows.


I don't expect anyone's going to look forward to coding like this:

int len = SendMessageA(handle, smjg.libs.winapi.LB_GETTEXTLEN, index, 0);

char[] buf = new char[len+1];

len = SendMessageA(handle, smjg.libs.winapi.LB_GETTEXT, index, cast(LPARAM) cast(char*) buf);

Have you considered creating new files with themes, such as std.c.windows.winbase?

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

"J C Calvarese" <jcc7@cox.net> wrote in message news:c85qmf$234n$1@digitaldaemon.com...
> Have you considered creating new files with themes, such as std.c.windows.winbase?

Yes, but does anybody use them, or do they just include windows.h?

Walter wrote:
> "J C Calvarese" <jcc7@cox.net> wrote in message
> news:c85qmf$234n$1@digitaldaemon.com...
> 
>>Have you considered creating new files with themes, such as
>>std.c.windows.winbase?
> 
> 
> Yes, but does anybody use them, or do they just include windows.h?

Is std.c.windows.windows going to stabilize or continue to grow sporadically? Can you mention when you make changes or do we have to find out from unexpected compile errors?

If you'd add new definitions in an orderly fashion, I think it might cause fewer unexpected conflicts for those programmers who have already added those definitions to their own projects.

Under the current system, every month or so new definitions appear without warning. When you'd fill holes in std.c.w.w (that I'd already added to my list), one of our projects wouldn't compile anymore. I know it's good to be king, but sometimes the serfs jump the moat and visit the next castle.

I've been telling people not to bother with using std.c.w.w and just use Mike Wynn's or Y. Tomino's port of the headers. So actually I've already lost faith in std.c.w.w anyways. :(

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/