Chris Swierczewski wrote:
> Hello,
>
> I'm having a compile issue with wrapping a certain C++ class. Allow me
> to describe the situation first before stating the issue.
>
> The Situation: the opentick API is a collection of cross-platform,
> cross-language libraries (and headers in the C++ flavor) for receiving
> live streams of financial data. (See www.opentick.com) Among the
> API/source languages available, there is a collection of
> cross-platform C++ headers along with a static library. What is meant
> by cross-platform? Well, depending on which platform you're using,
> different parts of the code are called and different macro definitions
> are made. For example, when compiling on a Linux system one must write
>
> #define __LINUX
>
> at the top of their code before calling the appropriate headers. Now,
> the main class is defined in the following way:
>
> class DLL_EXP OTClient:
> {
> public:
> ...
> }
>
> When running in the windows environment (that is, if you #define
> __WIN), DLL_EXP is set to "__declspec(dllexport)" which, to my
> understanding, has to do with using .dll files for callbacks akin to
> how twisted works. However, when compiling in the Linux environment,
> (#define __LINUX) the definition of the macro is "empty". That is, at
> some point before the definition of the class, we simply have
>
> #define DLL_EXP
>
> implying that no .dll calls need to be made.
>
> My Question (Finally): How do I go about wrapping this C++ class with
> this strange little define hanging around the class declaration?
> Methinks I'm having compile issues precisely because of this addition.
> I checked the Cython wiki and the Sage Wiki on wrapping C++ classes
> and couldn't find anything that looked like this. Thank you very much
> in advance for any help! (And thank you for such an awesome
> technology!)
>
Hi,
Have you tried passing -D__Linux at the build time of the extension?
I saw your discussion with Glenn and the removal of the
__declspec(dllexport) constructs as suggested by him will bite us in the
ass down the road since we intent to support MSVC for which the above
constructs are needed.
Cheers,
Michael
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
