On Mon, 9 Dec 2002, Francois Gouget wrote:
Also I would not be surprised if the MS macros were less flexible than
the ICOM macros and required that you have a compiler that can generate
Le lun 09/12/2002 à 19:15, Francois Gouget a écrit :
Or is it just that MSVC does not like the ',,' in macro invocations?
I'll do some more tests later today, but from my experience last week
with using the WINE headers to compile the tests on MSVC, it doesn't. It
caused an error, not only a
On Fri, 6 Dec 2002, Ove Kaaven wrote:
[...]
We may have to keep the macros anyway, there are headers that use them
that can't be generated from IDL, like the DirectX headers. I suppose they
could be converted to using the MS-style objbase.h macros by perl scripts
or by rewriting them from api
From: Ove Kaaven [EMAIL PROTECTED]
On 6 Dec 2002, Alexandre Julliard wrote:
Ove Kaaven [EMAIL PROTECTED] writes:
4) make widl not use macros at all, but emit full C and C++
definitions
directly (this is what midl.exe does, it seems)
I'd say this is the way to go if it's not too painful,
On Sun, 8 Dec 2002, Jeff Smith wrote:
I don't really care whether the ICOM_ macros go or stay in the current form,
but if they stay, they should at least be corrected in the following sense.
Presently, a typical macro in obj_base.h is
#define ICOM_METHOD4(ret,xfn,ta,na,tb,nb,tc,nc,td,nd)
I've submitted a patch to move the API prototypes out of obj_base.h, and
I'd now be ready to submit unknwn.idl and unknwn.h, which would also
supersede the interfaces defined in there, but I'm unsure about what to do
with the remainder of it, namely the ICOM_* macros in there.
Note that there's a
Ove Kaaven [EMAIL PROTECTED] writes:
4) make widl not use macros at all, but emit full C and C++ definitions
directly (this is what midl.exe does, it seems)
I'd say this is the way to go if it's not too painful, it seems to be
the most flexible. In any case obj_base.h has to go, so if we keep
