Mary hinton commented on PROTON-68:

This Jira is one of the simpler changes to make to the proton codebase to add 
the Windows port. But it is also a large code change, since we need to add a 
define to all the functions, classes, etc. that will be exported from the 
proton dll  and will also need to include a dll  defines header file in all the 
.c  files.

Before I set up this Jira I looked at the way QPID handled it and set up 
something I thought was similar.

QPID uses the XXX_ EXPORTS preprocessor definitions that are set up in cmake 
for the various dlls.The xxx represents  the dll project name. For example, in 
the qpidcommon project, it uses  qpidcommon_EXPORTS as a Preprocessor 
Definition. I used qpid_proton_EXPORTS.

Is there a defined interface for proton or is everything in the header files 
considered the interface?  I didn’t know what was exported just for testing to 
use in python(ruby, etc.)  and what would actually be exported in code that 
loads the dll, I used a separate define for the python. Thinking that a lot of 
the functions are only going to be exposed for testing and not for general use, 
I made a separate qpid_proton_python_EXPORTS.

The better approach would probably be to use one preprocessor define. It’s just 
that all the functions can be imported, which is  the default for gcc and mingw 
dlls, but not Visual Studio. So I’ll change the code to only use 
qpid_proton_EXPORTS (or qpid-proton_EXPORTS) as the preprocessor definition  
and only use one define. Using only one define should also remove the SWIGWIN 
problem, I ran into.

QPID also used a separate macro for classes and inlines.  For example, 
We could do that, or just use one define whether it is a function structure, 
inline etc..

We will also need to include the dll defines header file, in the .c files, so 
that posix operating systems can ignore the definitions and windows operating 
system will export or import the functions, classes, etc, as the case may be.

In QPID, qpidcommon dll uses CommonImportExport.h, qpidbroker dll used 
BrokerImportExport.h". I used QPID_PROTON.h, but  will use whatever  the proton 
developers group prefers. E.g. ImportExport.h or ProtonImportExport.h .

For the export/import defines themselves, an example of QPID is:
I used QPID_PROTON_API because  an example from Micorosft, used 

To be closer to the QPID practice, We could use:

The only problem with that is sometimes the EXTERN will be set to the IMPORT.
For example from the QPID code in the “else” below:

#if defined(COMMON_EXPORT) || defined (qpidcommon_EXPORTS)

So I think the PROTON_API is better for export or import, since it makes sense 
for either.

All the headers will need to be changed for a Windows port.
PROTON_API pn_data_t *pn_data(size_t capacity);
PROTON_API void pn_data_free(pn_data_t *data);
PROTON_API int pn_data_errno(pn_data_t *data);

Here’s a good discussion about building Win dlls  from the cmake perspective:
They used DLLDefines.h for their file, but ImportExport.h is probably better.

And another from Microsoft:

> 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

Reply via email to