You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by "Cliff Jansen (JIRA)" <ji...@apache.org> on 2012/10/10 18:43:02 UTC

[jira] [Commented] (PROTON-68) Porting Issue -- dll imports and exports on Visual Studio

    [ https://issues.apache.org/jira/browse/PROTON-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13473351#comment-13473351 ] 

Cliff Jansen commented on PROTON-68:
------------------------------------

It would be helpful in general for you to look in the qpid/cpp tree for solutions before building your own.  It doesn't help the community if there are differing approaches incorporated to the same problem.

Please see 

  qpid/cpp/include/qpid/ImportExport.h
  qpid/cpp/include/qpid/CommonImportExport.h


Note that CMake incorporates some magic to help here.  Check its documentation for details.

Also note that Microsoft compilers are not the sole ones that provide import/export directives.

I believe swig has already been taken into account too.

                
> Porting Issue -- dll imports and exports on Visual Studio
> ---------------------------------------------------------
>
>                 Key: PROTON-68
>                 URL: https://issues.apache.org/jira/browse/PROTON-68
>             Project: Qpid Proton
>          Issue Type: Improvement
>          Components: proton-c
>         Environment: Windows using Visual Studio 2010 
>            Reporter: Mary hinton
>              Labels: build
>
> Visual Studio dlls  use a macro to explicitly state which functions will be exported. I don’t have a list of all the functions that will be exported, so I just made the ones used by proton.c to be exportable. That left a lot that would be internal to the dll only. Then when I was working with the python, I realized that python was going to be importing a lot of functions from the dll that should never be exported unless testing, so I defined another macro for the python (ruby, etc) exported functions. Swig also had to be taken into account. 
> This is what I’m using right now and it should work on the Linux/Unix platform:
> #ifdef SWIGWIN
>        #define QPID_PROTON_API
> #else
>        #ifdef  _WINDOWS
>               #ifdef qpid_proton_EXPORTS
>                      #define QPID_PROTON_API __declspec(dllexport)
>                      #ifdef qpid_proton_python_EXPORTS
>                            #define QPID_PROTON_PY  __declspec(dllexport)
>                      #else
>                            #define QPID_PROTON_PY 
>                      #endif
>               #else
>                      #define QPID_PROTON_API __declspec(dllimport)
>                      #ifdef qpid_proton_python_IMPORTS
>                            #define QPID_PROTON_PY     __declspec(dllimport)
>                      #else
>                            #define QPID_PROTON_PY
>                      #endif
>               #endif
>        #else
>               #define QPID_PROTON_API
>        #endif
> #endif
> That means all the headers will need to be changed to include the macros.
> e.g.
> QPID_PROTON_API      pn_data_t *pn_data(size_t capacity);
> QPID_PROTON_API      void pn_data_free(pn_data_t *data);
> QPID_PROTON_PY       int pn_data_errno(pn_data_t *data);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira