Re: [PATCH] msvcmaker: added COM_NO_WINDOWS_H to support midl-generated headers for __WINESRC__ components.
2008/10/18 Reece Dunn msclrhd@googlemail.com:
When building the wine solution generated by msvcmaker, the components generate errors that projects that define __WINESRC__ should not include windows.h.
I tracked this error down to windows.h being included from unknwn.h (generated from unknwn.idl). This is from the code generated by VC9's midl compiler.
The midl generated code allows you to define COM_NO_WINDOWS_H to prevent the inclusion of windows.h. That define is thus added to those provided by msvcmaker.
Any reason why this hasn't been applied yet?
I've been testing with this applied and I believe it is an improvement and gets more DLLs compiling.
"Rob Shearman" robertshearman@gmail.com writes:
2008/10/18 Reece Dunn msclrhd@googlemail.com:
The midl generated code allows you to define COM_NO_WINDOWS_H to prevent the inclusion of windows.h. That define is thus added to those provided by msvcmaker.
Any reason why this hasn't been applied yet?
I've been testing with this applied and I believe it is an improvement and gets more DLLs compiling.
I don't think it's the right approach. If midl-generated code uses windows.h then widl-generated code should too, and we should ensure that it works in both cases, for instance by disabling the check when it's included from generated files or something along those lines.
2008/10/23 Alexandre Julliard julliard@winehq.org:
"Rob Shearman" robertshearman@gmail.com writes:
2008/10/18 Reece Dunn msclrhd@googlemail.com:
The midl generated code allows you to define COM_NO_WINDOWS_H to prevent the inclusion of windows.h. That define is thus added to those provided by msvcmaker.
Any reason why this hasn't been applied yet?
I've been testing with this applied and I believe it is an improvement and gets more DLLs compiling.
I don't think it's the right approach. If midl-generated code uses windows.h then widl-generated code should too, and we should ensure that it works in both cases, for instance by disabling the check when it's included from generated files or something along those lines.
Yes, I agree and I have plans to make widl do so. However, I don't see how we can detect if we are being included from widl- or midl-generated header files. My plan was to simply define COM_NO_WINDOWS_H for all __WINESRC__ files.
"Rob Shearman" robertshearman@gmail.com writes:
Yes, I agree and I have plans to make widl do so. However, I don't see how we can detect if we are being included from widl- or midl-generated header files. My plan was to simply define COM_NO_WINDOWS_H for all __WINESRC__ files.
That's certainly a valid solution, as long as it's done for all builds, not just the MSVC ones.
2008/10/23 Alexandre Julliard julliard@winehq.org:
"Rob Shearman" robertshearman@gmail.com writes:
2008/10/18 Reece Dunn msclrhd@googlemail.com:
The midl generated code allows you to define COM_NO_WINDOWS_H to prevent the inclusion of windows.h. That define is thus added to those provided by msvcmaker.
Any reason why this hasn't been applied yet?
I've been testing with this applied and I believe it is an improvement and gets more DLLs compiling.
I don't think it's the right approach. If midl-generated code uses windows.h then widl-generated code should too, and we should ensure that it works in both cases, for instance by disabling the check when it's included from generated files or something along those lines.
I was planning on adding COM_NO_WINDOWS_H explicitly to all source files in the dlls folder that require it. Once this is complete, the widl code generator can then be updated to support this behaviour (otherwise the widl change will break the Wine build).
This will also prevent the "symbol already defined" warning on the files that already define this when building with midl generated files using the VC compiler.
- Reece
-
Alexandre Julliard -
Reece Dunn -
Rob Shearman