[jira] [Created] (PROTON-57) Proton porting problems between current codebase and Visual Studio 2010 toolset
Mary hinton created PROTON-57: - Summary: Proton porting problems between current codebase and Visual Studio 2010 toolset Key: PROTON-57 URL: https://issues.apache.org/jira/browse/PROTON-57 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton This thread will be used to discuss the porting problems encountered using Visual Studio 2010 Here’s the first one to discuss: 1. Visual Studio doesn’t support variable length arrays. a. Currently using malloc()/realloc() in my port just to get it to compile and be able to report memory allocation errors. This is not what I want to submit to the proton group for memory allocation. b. Cliff had a good method that included setting up macros and replace the VLAs with alloca() in the Windows version, but it could still cause problems when the stack overflowed. VLAs can also run out of stack space. c. _malloca() should be a better way than _alloca() on Visual Studio. Any messages under 1K would be allocated out of the stack. Over 1K will use heap. If the average messages are under 1K, this may be the most efficient way in Visual Studio. _malloca() also has new security enhancements. 1. Using _malloca() in the Windows version and VLA in Linux would require two macros. The major difference for the Linux version would be to use the new macro for VLA and to include the new free macro even though there is nothing to free using VLA. In Visual Studio, _freea(buf) will not free anything if it is allocating off the stack. Linux can continue to use VLAs. #ifdef C99 #define PN_VLA(TYPE, buf, size) TYPE buf[size] #define PN_VLA_FREE #else #define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*) _malloca(size) #define PN_VLA_FREE(buf) _freea(buf) #endif d. If the average size messages to allocate out of the stack needs to be increased for performance reasons, we can set up a new memory model. The 1K is not adjustable for _malloca(). We can set up new macros along the lines of Microsoft’s suggestion below. “I would suggest something similar to what ATL does. Use alloca for small (where you define what that is) sizes and use heap allocation for larger ones. You can wrap the logic inside of a class or macros. To work around the fact that alloca isn't cleaned up at block scope, rewrite the block into functions or use lambdas. (I think alloca works inside of lambdas.)” -- 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
[jira] [Commented] (PROTON-57) Proton porting problems between current codebase and Visual Studio 2010 toolset
[
https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13469965#comment-13469965
]
Mary hinton commented on PROTON-57:
---
Thanks for the feedback,
We could substitute the alloca() for memory allocation that is not in a loop as
long as the buffers are reasonable sizes.
Since alloca() acquires new stack space each time it's called without reusing
space from previous calls, it's not a good idea to use it inside a loop.
The problem with anything being allocated out of the stack is the size of the
allocation. Stack space can still run out and alloca() will not warn us of a
problem. Using a loop in Linux containing a VLA to reallocate stack space, you
can still get segmentation failure if the allocation is large enough. Also if
large messages have been allocated on the stack, the memory can be reused, but
my understanding is that the stack doesn't shrink. The only way to recover
stack memory is when the thread exits.
I notice proton is initially set up with a stack space size of 1000, so it
may be expecting lots of large messages. I didn't know how many threads are
being created to handle buffers allocated out of the stack and if the number of
threads could be a problem for stack space usage.
Here's a snippet of code using the macros proposed:
Changed char data[ctx->size + 16];
server_callback()
{
char tagstr[1024];
char msg[10*1024];
PN_VLA(char, data, ctx->size + 16);
...
PN_VLA_FREE(data);
}
I saw various web sites arguing the pros and cons of VLAs, so maybe it is a
good idea to discuss VLAs in their own Jira thread.
> Proton porting problems between current codebase and Visual Studio 2010
> toolset
> ---
>
> Key: PROTON-57
> URL: https://issues.apache.org/jira/browse/PROTON-57
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Environment: Windows using Visual Studio 2010
>Reporter: Mary hinton
> Labels: build
>
> This thread will be used to discuss the porting problems encountered using
> Visual Studio 2010
> Here’s the first one to discuss:
>
> 1. Visual Studio doesn’t support variable length arrays.
> a. Currently using malloc()/realloc() in my port just to get it to
> compile and be able to report memory allocation errors. This is not what I
> want to submit to the proton group for memory allocation.
> b. Cliff had a good method that included setting up macros and replace
> the VLAs with alloca() in the Windows version, but it could still cause
> problems when the stack overflowed. VLAs can also run out of stack space.
> c. _malloca() should be a better way than _alloca() on Visual Studio.
> Any messages under 1K would be allocated out of the stack. Over 1K will use
> heap. If the average messages are under 1K, this may be the most efficient
> way in Visual Studio. _malloca() also has new security enhancements.
> 1. Using _malloca() in the Windows version and VLA in Linux would
> require two macros. The major difference for the Linux version would be to
> use the new macro for VLA and to include the new free macro even though there
> is nothing to free using VLA. In Visual Studio, _freea(buf) will not free
> anything if it is allocating off the stack.
> Linux can continue to use VLAs.
> #ifdef C99
> #define PN_VLA(TYPE, buf, size) TYPE buf[size]
> #define PN_VLA_FREE
> #else
> #define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*)
> _malloca(size)
>#define PN_VLA_FREE(buf) _freea(buf)
> #endif
> d. If the average size messages to allocate out of the stack needs to be
> increased for performance reasons, we can set up a new memory model. The 1K
> is not adjustable for _malloca().
> We can set up new macros along the lines of Microsoft’s suggestion below.
> “I would suggest something similar to what ATL does. Use alloca for small
> (where you define what that is) sizes and use heap allocation for larger
> ones. You can wrap the logic inside of a class or macros. To work around
> the fact that alloca isn't cleaned up at block scope, rewrite the block into
> functions or use lambdas. (I think alloca works inside of lambdas.)”
--
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
[jira] [Commented] (PROTON-57) Proton porting problems between current codebase and Visual Studio 2010 toolset
[
https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13470349#comment-13470349
]
Mary hinton commented on PROTON-57:
---
I’m going to list the problems with the biggest hits on the code first.
2. Initialization with braces is not supported by Visual Studio. I used
ifdef(s) in the codebase to keep the current code working for Linux, but
changed quite a few of these to get it to compile in Visual Studio.
Eample1
ssize_t pn_data_encode(pn_data_t *data, char *bytes, size_t size)
{
#ifndef _WINDOWS
pn_atom_t atoms[data->size + data->extras];
pn_atoms_t latoms = {.size=data->size + data->extras, .start=atoms};
#else
PN_VLA(pn_atom_t, atoms, data->size + data->extras);
pn_atoms_t latoms;
latoms.size = data->size + data->extras;
latoms.start = atoms;
#endif
pn_data_as_atoms(data, &latoms);
pn_bytes_t lbytes = pn_bytes(size, bytes);
int err = pn_encode_atoms(&lbytes, &latoms);
PN_VLA_FREE(atoms);
if (err) return err;
return lbytes.size;
}
Example 2
#ifndef _WINDOWS
return (pn_bytes_t) {size, start};
#else
pn_bytes_t pnBytes;
pnBytes.size = size;
pnBytes.start= start;
return pnBytes;
#endif
Example 3
pn_do_transfer()
#ifndef _WINDOWS
delivery = pn_delivery(link, pn_dtag(tag.start, tag.size));
#else
pn_delivery_tag_t delivt;
delivt.bytes = tag.start;
delivt.size = tag.size;
delivery = pn_delivery(link, delivt);
#endif
> Proton porting problems between current codebase and Visual Studio 2010
> toolset
> ---
>
> Key: PROTON-57
> URL: https://issues.apache.org/jira/browse/PROTON-57
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Environment: Windows using Visual Studio 2010
>Reporter: Mary hinton
> Labels: build
>
> This thread will be used to discuss the porting problems encountered using
> Visual Studio 2010
> Here’s the first one to discuss:
>
> 1. Visual Studio doesn’t support variable length arrays.
> a. Currently using malloc()/realloc() in my port just to get it to
> compile and be able to report memory allocation errors. This is not what I
> want to submit to the proton group for memory allocation.
> b. Cliff had a good method that included setting up macros and replace
> the VLAs with alloca() in the Windows version, but it could still cause
> problems when the stack overflowed. VLAs can also run out of stack space.
> c. _malloca() should be a better way than _alloca() on Visual Studio.
> Any messages under 1K would be allocated out of the stack. Over 1K will use
> heap. If the average messages are under 1K, this may be the most efficient
> way in Visual Studio. _malloca() also has new security enhancements.
> 1. Using _malloca() in the Windows version and VLA in Linux would
> require two macros. The major difference for the Linux version would be to
> use the new macro for VLA and to include the new free macro even though there
> is nothing to free using VLA. In Visual Studio, _freea(buf) will not free
> anything if it is allocating off the stack.
> Linux can continue to use VLAs.
> #ifdef C99
> #define PN_VLA(TYPE, buf, size) TYPE buf[size]
> #define PN_VLA_FREE
> #else
> #define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*)
> _malloca(size)
>#define PN_VLA_FREE(buf) _freea(buf)
> #endif
> d. If the average size messages to allocate out of the stack needs to be
> increased for performance reasons, we can set up a new memory model. The 1K
> is not adjustable for _malloca().
> We can set up new macros along the lines of Microsoft’s suggestion below.
> “I would suggest something similar to what ATL does. Use alloca for small
> (where you define what that is) sizes and use heap allocation for larger
> ones. You can wrap the logic inside of a class or macros. To work around
> the fact that alloca isn't cleaned up at block scope, rewrite the block into
> functions or use lambdas. (I think alloca works inside of lambdas.)”
--
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
[jira] [Commented] (PROTON-57) Proton porting problems between current codebase and Visual Studio 2010 toolset
[ https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13471371#comment-13471371 ] Mary hinton commented on PROTON-57: --- I forgot to put the sizeof(TYPE) for Windows in the Macro for Windows port #ifdef C99 #define PN_VLA(TYPE, buf, size) TYPE buf[size] #define PN_VLA_FREE #else #define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*) _malloca((size) * sizeof(TYPE)) #define PN_VLA_FREE(buf) _freea(buf) #endif > Proton porting problems between current codebase and Visual Studio 2010 > toolset > --- > > Key: PROTON-57 > URL: https://issues.apache.org/jira/browse/PROTON-57 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Labels: build > > This thread will be used to discuss the porting problems encountered using > Visual Studio 2010 > Here’s the first one to discuss: > > 1. Visual Studio doesn’t support variable length arrays. > a. Currently using malloc()/realloc() in my port just to get it to > compile and be able to report memory allocation errors. This is not what I > want to submit to the proton group for memory allocation. > b. Cliff had a good method that included setting up macros and replace > the VLAs with alloca() in the Windows version, but it could still cause > problems when the stack overflowed. VLAs can also run out of stack space. > c. _malloca() should be a better way than _alloca() on Visual Studio. > Any messages under 1K would be allocated out of the stack. Over 1K will use > heap. If the average messages are under 1K, this may be the most efficient > way in Visual Studio. _malloca() also has new security enhancements. > 1. Using _malloca() in the Windows version and VLA in Linux would > require two macros. The major difference for the Linux version would be to > use the new macro for VLA and to include the new free macro even though there > is nothing to free using VLA. In Visual Studio, _freea(buf) will not free > anything if it is allocating off the stack. > Linux can continue to use VLAs. > #ifdef C99 > #define PN_VLA(TYPE, buf, size) TYPE buf[size] > #define PN_VLA_FREE > #else > #define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*) > _malloca(size) >#define PN_VLA_FREE(buf) _freea(buf) > #endif > d. If the average size messages to allocate out of the stack needs to be > increased for performance reasons, we can set up a new memory model. The 1K > is not adjustable for _malloca(). > We can set up new macros along the lines of Microsoft’s suggestion below. > “I would suggest something similar to what ATL does. Use alloca for small > (where you define what that is) sizes and use heap allocation for larger > ones. You can wrap the logic inside of a class or macros. To work around > the fact that alloca isn't cleaned up at block scope, rewrite the block into > functions or use lambdas. (I think alloca works inside of lambdas.)” -- 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
[jira] [Commented] (PROTON-57) Proton porting problems between current codebase and Visual Studio 2010 toolset
[ https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13471785#comment-13471785 ] Mary hinton commented on PROTON-57: --- proton.c server_callback(pn_connector_t *ctor) -- char iresp[n]; -- char data[ctx->size + 16]; client_callback(pn_connector_t *ctor) -- char msg[ctx->size] -- char data[ctx->size + 16]; codec.c pn_print_atoms(const pn_atoms_t * atoms) -- char buf[size] pn_data_encode(pn_data_t *data, char *bytes, size_t size) -- pn_atom_t atoms[data->size + data->extras]; pn_data_decode(pn_data_t *data, char *bytes, size_t size) -- pn_atom_t atoms[asize]; messenger.c pn_messenger_resolve(pn_messenger_t *messenger, char *address, char **name) -- char domain[strlen(address) + 1]; pn_messenger_link(pn_messenger_t *messenger, const char *address, bool sender) -- char copy[(address ? strlen(address) : 0) + 1]; pn_messenger_subscribe(pn_messenger_t *messenger, const char *source) -- char copy[strlen(source) + 1]; outward_munge(pn_messenger_t *mng, pn_message_t *msg) -- char buf[len + strlen(mng->name) + 4]; -- char buf[strlen(mng->name) + 4]; pn_messenger_put(pn_messenger_t *messenger, pn_message_t *msg) -- char encoded[size]; sasl.c pn_sasl_plain(pn_sasl_t *sasl, const char *username, const char *password)-- char iresp[size]; pn_fprint_data(FILE *stream, const char *bytes, size_t size) -- char buf[capacity]; This list only includes the VLAs and doesn't include constant size arrays. > Proton porting problems between current codebase and Visual Studio 2010 > toolset > --- > > Key: PROTON-57 > URL: https://issues.apache.org/jira/browse/PROTON-57 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Labels: build > > This thread will be used to discuss the porting problems encountered using > Visual Studio 2010 > Here’s the first one to discuss: > > 1. Visual Studio doesn’t support variable length arrays. > a. Currently using malloc()/realloc() in my port just to get it to > compile and be able to report memory allocation errors. This is not what I > want to submit to the proton group for memory allocation. > b. Cliff had a good method that included setting up macros and replace > the VLAs with alloca() in the Windows version, but it could still cause > problems when the stack overflowed. VLAs can also run out of stack space. > c. _malloca() should be a better way than _alloca() on Visual Studio. > Any messages under 1K would be allocated out of the stack. Over 1K will use > heap. If the average messages are under 1K, this may be the most efficient > way in Visual Studio. _malloca() also has new security enhancements. > 1. Using _malloca() in the Windows version and VLA in Linux would > require two macros. The major difference for the Linux version would be to > use the new macro for VLA and to include the new free macro even though there > is nothing to free using VLA. In Visual Studio, _freea(buf) will not free > anything if it is allocating off the stack. > Linux can continue to use VLAs. > #ifdef C99 > #define PN_VLA(TYPE, buf, size) TYPE buf[size] > #define PN_VLA_FREE > #else > #define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*) > _malloca(size) >#define PN_VLA_FREE(buf) _freea(buf) > #endif > d. If the average size messages to allocate out of the stack needs to be > increased for performance reasons, we can set up a new memory model. The 1K > is not adjustable for _malloca(). > We can set up new macros along the lines of Microsoft’s suggestion below. > “I would suggest something similar to what ATL does. Use alloca for small > (where you define what that is) sizes and use heap allocation for larger > ones. You can wrap the logic inside of a class or macros. To work around > the fact that alloca isn't cleaned up at block scope, rewrite the block into > functions or use lambdas. (I think alloca works inside of lambdas.)” -- 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/
[jira] [Created] (PROTON-67) Porting Issue -- Initialization with braces is not supported by Visual Studio.
Mary hinton created PROTON-67:
-
Summary: Porting Issue -- Initialization with braces is not
supported by Visual Studio.
Key: PROTON-67
URL: https://issues.apache.org/jira/browse/PROTON-67
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c
Environment: Windows using Visual Studio 2010
Reporter: Mary hinton
In the Windows port, I used ifdef(s) for the initializations to keep the
current code for Linux, and added code to compile in Visual Studio. If there is
no objection, maybe we could replace the current initialization code with the
Visual Studio code and remove the #ifdef(s).
Here's some examples:
Eample1
ssize_t pn_data_encode(pn_data_t *data, char *bytes, size_t size)
{
#ifndef _WINDOWS
pn_atoms_t latoms = {.size=data->size + data->extras, .start=atoms};
#else
pn_atoms_t latoms;
latoms.size = data->size + data->extras;
latoms.start = atoms;
#endif
Example 2
#ifndef _WINDOWS
return (pn_bytes_t) {size, start};
#else
pn_bytes_t pnBytes;
pnBytes.size = size;
pnBytes.start= start;
return pnBytes;
#endif
Example 3
pn_do_transfer()
#ifndef _WINDOWS
delivery = pn_delivery(link, pn_dtag(tag.start, tag.size));
#else
pn_delivery_tag_t delivt;
delivt.bytes = tag.start;
delivt.size = tag.size;
delivery = pn_delivery(link, delivt);
#endif
--
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
[jira] [Created] (PROTON-68) Porting Issue -- dll imports and exports on Visual Studio
Mary hinton created PROTON-68: - Summary: 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 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
[jira] [Commented] (PROTON-67) Porting Issue -- Initialization with braces is not supported by Visual Studio.
[
https://issues.apache.org/jira/browse/PROTON-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13473427#comment-13473427
]
Mary hinton commented on PROTON-67:
---
You're right. I should have said Visual Studio does not support "Designated
initializers"
Thanks,
Mary
> Porting Issue -- Initialization with braces is not supported by Visual Studio.
> --
>
> Key: PROTON-67
> URL: https://issues.apache.org/jira/browse/PROTON-67
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Environment: Windows using Visual Studio 2010
>Reporter: Mary hinton
> Labels: build
>
> In the Windows port, I used ifdef(s) for the initializations to keep the
> current code for Linux, and added code to compile in Visual Studio. If there
> is no objection, maybe we could replace the current initialization code with
> the Visual Studio code and remove the #ifdef(s).
> Here's some examples:
> Eample1
> ssize_t pn_data_encode(pn_data_t *data, char *bytes, size_t size)
> {
> #ifndef _WINDOWS
>pn_atoms_t latoms = {.size=data->size + data->extras, .start=atoms};
> #else
> pn_atoms_t latoms;
>latoms.size = data->size + data->extras;
>latoms.start = atoms;
> #endif
>
>
> Example 2
>
> #ifndef _WINDOWS
> return (pn_bytes_t) {size, start};
> #else
> pn_bytes_t pnBytes;
> pnBytes.size = size;
> pnBytes.start= start;
> return pnBytes;
> #endif
>
> Example 3
>
> pn_do_transfer()
>
> #ifndef _WINDOWS
> delivery = pn_delivery(link, pn_dtag(tag.start, tag.size));
> #else
> pn_delivery_tag_t delivt;
> delivt.bytes = tag.start;
> delivt.size = tag.size;
> delivery = pn_delivery(link, delivt);
> #endif
--
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
[jira] [Commented] (PROTON-57) Proton porting problems between current codebase and Visual Studio 2010 toolset
[ https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474090#comment-13474090 ] Mary hinton commented on PROTON-57: --- For the ones you want a fixed maximum length, is there a specific size for printing the atoms and data that you want? The same with the maximum length for the addresses, what size would you like to specify? “pn_data_encode/decode(...) For these we should add a dedicated array to pn_data_t and grow the array as needed.” pn_data_encode() used a VLA for allocating atoms on the stack. Did you want me to put in a pointer to atoms in pn_data_t and then allocate it out of heap and if needed realloc() and free it in pn_data_free()? > Proton porting problems between current codebase and Visual Studio 2010 > toolset > --- > > Key: PROTON-57 > URL: https://issues.apache.org/jira/browse/PROTON-57 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Labels: build > > This thread will be used to discuss the porting problems encountered using > Visual Studio 2010 > Here’s the first one to discuss: > > 1. Visual Studio doesn’t support variable length arrays. > a. Currently using malloc()/realloc() in my port just to get it to > compile and be able to report memory allocation errors. This is not what I > want to submit to the proton group for memory allocation. > b. Cliff had a good method that included setting up macros and replace > the VLAs with alloca() in the Windows version, but it could still cause > problems when the stack overflowed. VLAs can also run out of stack space. > c. _malloca() should be a better way than _alloca() on Visual Studio. > Any messages under 1K would be allocated out of the stack. Over 1K will use > heap. If the average messages are under 1K, this may be the most efficient > way in Visual Studio. _malloca() also has new security enhancements. > 1. Using _malloca() in the Windows version and VLA in Linux would > require two macros. The major difference for the Linux version would be to > use the new macro for VLA and to include the new free macro even though there > is nothing to free using VLA. In Visual Studio, _freea(buf) will not free > anything if it is allocating off the stack. > Linux can continue to use VLAs. > #ifdef C99 > #define PN_VLA(TYPE, buf, size) TYPE buf[size] > #define PN_VLA_FREE > #else > #define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*) > _malloca(size) >#define PN_VLA_FREE(buf) _freea(buf) > #endif > d. If the average size messages to allocate out of the stack needs to be > increased for performance reasons, we can set up a new memory model. The 1K > is not adjustable for _malloca(). > We can set up new macros along the lines of Microsoft’s suggestion below. > “I would suggest something similar to what ATL does. Use alloca for small > (where you define what that is) sizes and use heap allocation for larger > ones. You can wrap the logic inside of a class or macros. To work around > the fact that alloca isn't cleaned up at block scope, rewrite the block into > functions or use lambdas. (I think alloca works inside of lambdas.)” -- 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
[jira] [Commented] (PROTON-67) Porting Issue -- Initialization with braces is not supported by Visual Studio.
[
https://issues.apache.org/jira/browse/PROTON-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13474125#comment-13474125
]
Mary hinton commented on PROTON-67:
---
Hi Cliff and Andrew,
Whatever you want to use for the #ifdef is fine, as long as it distinguishes
the Visual Studio port. I'll change the #ifdef's accordingly.
I did find this about different compilers:
"Notice that not all compliant compilers provides the correct pre-defined
macros. For example, Microsoft Visual C++ does not define __STDC__, or Sun
Workshop 4.2 supports C94 without setting __STDC_VERSION__ to the proper value.
Extra checks for such compilers must be added.
Notice that some compilers, such as the HP aC++, use the value 199707L to
indicate the C++98 standard. This value was used in an earlier proposal of the
C++98 standard."
> Porting Issue -- Initialization with braces is not supported by Visual Studio.
> --
>
> Key: PROTON-67
> URL: https://issues.apache.org/jira/browse/PROTON-67
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Environment: Windows using Visual Studio 2010
>Reporter: Mary hinton
> Labels: build
>
> In the Windows port, I used ifdef(s) for the initializations to keep the
> current code for Linux, and added code to compile in Visual Studio. If there
> is no objection, maybe we could replace the current initialization code with
> the Visual Studio code and remove the #ifdef(s).
> Here's some examples:
> Eample1
> ssize_t pn_data_encode(pn_data_t *data, char *bytes, size_t size)
> {
> #ifndef _WINDOWS
>pn_atoms_t latoms = {.size=data->size + data->extras, .start=atoms};
> #else
> pn_atoms_t latoms;
>latoms.size = data->size + data->extras;
>latoms.start = atoms;
> #endif
>
>
> Example 2
>
> #ifndef _WINDOWS
> return (pn_bytes_t) {size, start};
> #else
> pn_bytes_t pnBytes;
> pnBytes.size = size;
> pnBytes.start= start;
> return pnBytes;
> #endif
>
> Example 3
>
> pn_do_transfer()
>
> #ifndef _WINDOWS
> delivery = pn_delivery(link, pn_dtag(tag.start, tag.size));
> #else
> pn_delivery_tag_t delivt;
> delivt.bytes = tag.start;
> delivt.size = tag.size;
> delivery = pn_delivery(link, delivt);
> #endif
--
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
[jira] [Updated] (PROTON-57) Proton porting problems between current codebase and Visual Studio 2010 toolset
[ https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-57: -- Attachment: codec.c.patch messenger.c.patch Added patches for removing VLAs from code. > Proton porting problems between current codebase and Visual Studio 2010 > toolset > --- > > Key: PROTON-57 > URL: https://issues.apache.org/jira/browse/PROTON-57 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Labels: build > Attachments: codec.c.patch, messenger.c.patch > > > This thread will be used to discuss the porting problems encountered using > Visual Studio 2010 > Here’s the first one to discuss: > > 1. Visual Studio doesn’t support variable length arrays. > a. Currently using malloc()/realloc() in my port just to get it to > compile and be able to report memory allocation errors. This is not what I > want to submit to the proton group for memory allocation. > b. Cliff had a good method that included setting up macros and replace > the VLAs with alloca() in the Windows version, but it could still cause > problems when the stack overflowed. VLAs can also run out of stack space. > c. _malloca() should be a better way than _alloca() on Visual Studio. > Any messages under 1K would be allocated out of the stack. Over 1K will use > heap. If the average messages are under 1K, this may be the most efficient > way in Visual Studio. _malloca() also has new security enhancements. > 1. Using _malloca() in the Windows version and VLA in Linux would > require two macros. The major difference for the Linux version would be to > use the new macro for VLA and to include the new free macro even though there > is nothing to free using VLA. In Visual Studio, _freea(buf) will not free > anything if it is allocating off the stack. > Linux can continue to use VLAs. > #ifdef C99 > #define PN_VLA(TYPE, buf, size) TYPE buf[size] > #define PN_VLA_FREE > #else > #define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*) > _malloca(size) >#define PN_VLA_FREE(buf) _freea(buf) > #endif > d. If the average size messages to allocate out of the stack needs to be > increased for performance reasons, we can set up a new memory model. The 1K > is not adjustable for _malloca(). > We can set up new macros along the lines of Microsoft’s suggestion below. > “I would suggest something similar to what ATL does. Use alloca for small > (where you define what that is) sizes and use heap allocation for larger > ones. You can wrap the logic inside of a class or macros. To work around > the fact that alloca isn't cleaned up at block scope, rewrite the block into > functions or use lambdas. (I think alloca works inside of lambdas.)” -- 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
[jira] [Created] (PROTON-98) Porting Issue -- Visual Studio compiler requires explicit casts
Mary hinton created PROTON-98: - Summary: Porting Issue -- Visual Studio compiler requires explicit casts Key: PROTON-98 URL: https://issues.apache.org/jira/browse/PROTON-98 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton I would like to get the code changed to add explicit casts where the Visual Studio compiler requires it. The GNU compiler isn’t so picky, but we need the explicit casts for Visual Studio tools. The problem is in many of the files. C:\qpid\qpid\proton\proton-c\src\proton.c(278): struct client_context *ctx = (client_context *) pn_connector_context(ctor); // explicit cast C:\qpid\qpid\proton\proton-c\src\buffer.c(41): pn_buffer_t *buf = (pn_buffer_t *) malloc(sizeof(pn_buffer_t)); // explicit cast C:\qpid\qpid\proton\proton-c\src\buffer.c(45): buf->bytes = capacity ? (char *) malloc(capacity) : NULL; // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(706):return (pn_type_t) PN_ARG_ERR;// explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(758):return (pn_type_t) PN_ARG_ERR;// explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1210):atom->u.type = (pn_type_t) va_arg(*ap, int); // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1311): char **sptr = (char **) ptr; // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1875): pn_data_t *data = (pn_data_t *) malloc(sizeof(pn_data_t)); // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1878): data->nodes = capacity ? (pn_node_t *) malloc(capacity * sizeof(pn_node_t)) : NULL; // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1931): data->nodes = (pn_node_t *) realloc(data->nodes, data->capacity * sizeof(pn_node_t)); // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(2151):char **sptr = (char**) ptr; // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3114):return (pn_type_t) -1; // explicit cast C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3764):return (pn_type_t) -1; // explicit cast C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(32): pn_dispatcher_t *disp = (pn_dispatcher_t *) calloc(sizeof(pn_dispatcher_t), 1); // explicit cast C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(47): disp->output = (char *) malloc(disp->capacity);// explicit cast C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(248): disp->output = (char *) realloc(disp->output, disp->capacity); // explicit cast C:\qpid\qpid\proton\proton-c\src\driver.c(193): pn_listener_t *l = (pn_listener_t *) malloc(sizeof(pn_listener_t)); // explicit cast C:\qpid\qpid\proton\proton-c\src\driver.c(410): pn_connector_t *c = (pn_connector_t *) malloc(sizeof(pn_connector_t)); // explicit cast C:\qpid\qpid\proton\proton-c\src\driver.c(656): pn_driver_t *d = (pn_driver_t *) malloc(sizeof(pn_driver_t));// explicit cast C:\qpid\qpid\proton\proton-c\src\driver.c(748):d->fds = (pollfd *) realloc(d->fds, d->capacity*sizeof(struct pollfd));// explicit cast C:\qpid\qpid\proton\proton-c\src\engine\engine.c(47): db->deliveries = (pn_delivery_state_t *) malloc(sizeof(pn_delivery_state_t) * capacity);// explicit cast C:\qpid\qpid\proton\proton-c\src\engine\engine.c(438): pn_connection_t *conn = (pn_connection_t *)malloc(sizeof(pn_connection_t)); // explicit cast C:\qpid\qpid\proton\proton-c\src\engine\engine.c(730): pn_session_t *ssn = (pn_session_t *) malloc(sizeof(pn_session_t));// explicit cast C:\qpid\qpid\proton\proton-c\src\engine\engine.c(866): pn_transport_t *transport = (pn_transport_t *) malloc(sizeof(pn_transport_t)); // explicit cast C:\qpid\qpid\proton\proton-c\src\engine\engine.c(964): return terminus ? terminus->type : (pn_terminus_type_t) 0; // explicit cast C:\qpid\qpid\proton\proton-c\src\engine\engine.c(982): return terminus ? terminus->durability : (pn_durability_t) 0; // explicit cast C:\qpid\qpid\proton\proton
[jira] [Commented] (PROTON-98) Porting Issue -- Visual Studio compiler requires explicit casts
[ https://issues.apache.org/jira/browse/PROTON-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481458#comment-13481458 ] Mary hinton commented on PROTON-98: --- Missed the second one in sasl.c C:\qpid\qpid\proton\proton-c\src\sasl\sasl.c(362): pn_sasl_t *sasl = (pn_sasl_t *) disp->context;// explicit cast > Porting Issue -- Visual Studio compiler requires explicit casts > --- > > Key: PROTON-98 > URL: https://issues.apache.org/jira/browse/PROTON-98 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Labels: build > > I would like to get the code changed to add explicit casts where the Visual > Studio compiler requires it. > The GNU compiler isn’t so picky, but we need the explicit casts for Visual > Studio tools. > The problem is in many of the files. > C:\qpid\qpid\proton\proton-c\src\proton.c(278): struct client_context *ctx > = (client_context *) pn_connector_context(ctor);// explicit > cast > C:\qpid\qpid\proton\proton-c\src\buffer.c(41): pn_buffer_t *buf = > (pn_buffer_t *) malloc(sizeof(pn_buffer_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\buffer.c(45): buf->bytes = capacity ? > (char *) malloc(capacity) : NULL; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(706):return (pn_type_t) > PN_ARG_ERR; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(758):return (pn_type_t) > PN_ARG_ERR; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1210):atom->u.type = > (pn_type_t) va_arg(*ap, int); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1311): char **sptr > = (char **) ptr; // explicit > cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1875): pn_data_t *data = > (pn_data_t *) malloc(sizeof(pn_data_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1878): data->nodes = > capacity ? (pn_node_t *) malloc(capacity * sizeof(pn_node_t)) : NULL; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1931): data->nodes = > (pn_node_t *) realloc(data->nodes, data->capacity * sizeof(pn_node_t)); > // explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(2151):char > **sptr = (char**) ptr; > // explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3114):return (pn_type_t) > -1; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3764):return (pn_type_t) > -1; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(32): > pn_dispatcher_t *disp = (pn_dispatcher_t *) calloc(sizeof(pn_dispatcher_t), > 1); // explicit cast > C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(47): disp->output > = (char *) malloc(disp->capacity); // explicit > cast > C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(248): > disp->output = (char *) realloc(disp->output, disp->capacity);// > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(193): pn_listener_t *l = > (pn_listener_t *) malloc(sizeof(pn_listener_t));// > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(410): pn_connector_t *c = > (pn_connector_t *) malloc(sizeof(pn_connector_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(656): pn_driver_t *d = > (pn_driver_t *) malloc(sizeof(pn_driver_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(748):d->fds = (pollfd *) > realloc(d->fds, d->capacity*sizeof(struct pollfd)); // explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(47): db->deliveries = > (pn_delivery_state_t *) malloc(sizeof(pn_delivery_state_t) * capacity);// > explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(438): pn_connection_t > *conn = (pn_connection_t *)malloc(sizeof(pn_connection_t)); > // explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(730): pn_session_t *ssn = > (pn_session_t *) malloc(sizeof(pn_session
[jira] [Created] (PROTON-99) Porting Issue -- pn_dtag macro does not compile with Visual Studio compiler
Mary hinton created PROTON-99:
-
Summary: Porting Issue -- pn_dtag macro does not compile with
Visual Studio compiler
Key: PROTON-99
URL: https://issues.apache.org/jira/browse/PROTON-99
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c
Environment: Windows using Visual Studio 2010
Reporter: Mary hinton
I would like to replace the pn_dtag macro with a function that will compile
using either GNU or Visual Studio compilers.
engine.h
Replace:
#define pn_dtag(BYTES, SIZE) ((pn_delivery_tag_t) {(SIZE), (BYTES)}
With:
pn_delivery_tag_t pn_dtag(const char *bytes, size_t size);
engine.c
Add:
pn_delivery_tag_t pn_dtag(const char *bytes, size_t size)
{
pn_delivery_tag_t delivt;
delivt.bytes = bytes;
delivt.size = size;
return delivt;
}
--
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
[jira] [Updated] (PROTON-98) Porting Issue -- Visual Studio compiler requires explicit casts
[ https://issues.apache.org/jira/browse/PROTON-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-98: -- Attachment: ExplicitCasts.patch Here is a patch file with explicit casts > Porting Issue -- Visual Studio compiler requires explicit casts > --- > > Key: PROTON-98 > URL: https://issues.apache.org/jira/browse/PROTON-98 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Labels: build > Attachments: ExplicitCasts.patch > > > I would like to get the code changed to add explicit casts where the Visual > Studio compiler requires it. > The GNU compiler isn’t so picky, but we need the explicit casts for Visual > Studio tools. > The problem is in many of the files. > C:\qpid\qpid\proton\proton-c\src\proton.c(278): struct client_context *ctx > = (client_context *) pn_connector_context(ctor);// explicit > cast > C:\qpid\qpid\proton\proton-c\src\buffer.c(41): pn_buffer_t *buf = > (pn_buffer_t *) malloc(sizeof(pn_buffer_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\buffer.c(45): buf->bytes = capacity ? > (char *) malloc(capacity) : NULL; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(706):return (pn_type_t) > PN_ARG_ERR; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(758):return (pn_type_t) > PN_ARG_ERR; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1210):atom->u.type = > (pn_type_t) va_arg(*ap, int); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1311): char **sptr > = (char **) ptr; // explicit > cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1875): pn_data_t *data = > (pn_data_t *) malloc(sizeof(pn_data_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1878): data->nodes = > capacity ? (pn_node_t *) malloc(capacity * sizeof(pn_node_t)) : NULL; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1931): data->nodes = > (pn_node_t *) realloc(data->nodes, data->capacity * sizeof(pn_node_t)); > // explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(2151):char > **sptr = (char**) ptr; > // explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3114):return (pn_type_t) > -1; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3764):return (pn_type_t) > -1; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(32): > pn_dispatcher_t *disp = (pn_dispatcher_t *) calloc(sizeof(pn_dispatcher_t), > 1); // explicit cast > C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(47): disp->output > = (char *) malloc(disp->capacity); // explicit > cast > C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(248): > disp->output = (char *) realloc(disp->output, disp->capacity);// > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(193): pn_listener_t *l = > (pn_listener_t *) malloc(sizeof(pn_listener_t));// > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(410): pn_connector_t *c = > (pn_connector_t *) malloc(sizeof(pn_connector_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(656): pn_driver_t *d = > (pn_driver_t *) malloc(sizeof(pn_driver_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(748):d->fds = (pollfd *) > realloc(d->fds, d->capacity*sizeof(struct pollfd)); // explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(47): db->deliveries = > (pn_delivery_state_t *) malloc(sizeof(pn_delivery_state_t) * capacity);// > explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(438): pn_connection_t > *conn = (pn_connection_t *)malloc(sizeof(pn_connection_t)); > // explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(730): pn_session_t *ssn = > (pn_session_t *) malloc(sizeof(pn_session_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(
[jira] [Created] (PROTON-122) Porting Issue -- Visual Studio compilers have different header files
Mary hinton created PROTON-122: -- Summary: Porting Issue -- Visual Studio compilers have different header files Key: PROTON-122 URL: https://issues.apache.org/jira/browse/PROTON-122 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 10 Reporter: Mary hinton Visual Studio compilers have different header files. I looked through the files that qpid cpp uses for including Visual Studio header files. It looks like most of the diffences in header files are set up in Boost. Boost uses the macro BOOST_WINDOWS. Maybe we could use PROTON_WINDOWS for including the windows header files. If you don't want a new macro, we can use one of the Visual Studio specific macro (_WINDOWS) for the header files. It's not really a CPLUSPLUS vs. C issue, since many of the header files are specific to Windows. (for example winsock2.h which is used by C++ and C in Visual Studio). Also, some of the current header files are not used on Windows, but may be used by CYGWIN or MinGW. If this sounds okay, I'll set up a patch for including the necessary windows header files. -- 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
[jira] [Created] (PROTON-123) Porting Issue -- Visual Studio compilers do not support %zu and %zi (C99) in printf statements
Mary hinton created PROTON-123: -- Summary: Porting Issue -- Visual Studio compilers do not support %zu and %zi (C99) in printf statements Key: PROTON-123 URL: https://issues.apache.org/jira/browse/PROTON-123 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Replaced the %zu and %zi with %lu and %li. %li for ssize_t and %lu for size_t -- 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
[jira] [Created] (PROTON-124) Porting Issue -- Visual Studio requires WSAStartup() and WSACleanup() to initialize\cleanup the Windows socket dll
Mary hinton created PROTON-124: -- Summary: Porting Issue -- Visual Studio requires WSAStartup() and WSACleanup() to initialize\cleanup the Windows socket dll Key: PROTON-124 URL: https://issues.apache.org/jira/browse/PROTON-124 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Put the WSAStartup code in pn_driver() and the WSACleanup() code in pn_driver_free(). Used a _WINDOWS macro around the Windows code. -- 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
[jira] [Updated] (PROTON-98) Porting Issue -- Visual Studio compiler requires explicit casts
[ https://issues.apache.org/jira/browse/PROTON-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-98: -- Attachment: explicitCasts2.patch morxplicit casts that need to be added for Visual Studio port > Porting Issue -- Visual Studio compiler requires explicit casts > --- > > Key: PROTON-98 > URL: https://issues.apache.org/jira/browse/PROTON-98 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Labels: build > Attachments: explicitCasts2.patch, ExplicitCasts.patch > > > I would like to get the code changed to add explicit casts where the Visual > Studio compiler requires it. > The GNU compiler isn’t so picky, but we need the explicit casts for Visual > Studio tools. > The problem is in many of the files. > C:\qpid\qpid\proton\proton-c\src\proton.c(278): struct client_context *ctx > = (client_context *) pn_connector_context(ctor);// explicit > cast > C:\qpid\qpid\proton\proton-c\src\buffer.c(41): pn_buffer_t *buf = > (pn_buffer_t *) malloc(sizeof(pn_buffer_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\buffer.c(45): buf->bytes = capacity ? > (char *) malloc(capacity) : NULL; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(706):return (pn_type_t) > PN_ARG_ERR; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(758):return (pn_type_t) > PN_ARG_ERR; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1210):atom->u.type = > (pn_type_t) va_arg(*ap, int); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1311): char **sptr > = (char **) ptr; // explicit > cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1875): pn_data_t *data = > (pn_data_t *) malloc(sizeof(pn_data_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1878): data->nodes = > capacity ? (pn_node_t *) malloc(capacity * sizeof(pn_node_t)) : NULL; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1931): data->nodes = > (pn_node_t *) realloc(data->nodes, data->capacity * sizeof(pn_node_t)); > // explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(2151):char > **sptr = (char**) ptr; > // explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3114):return (pn_type_t) > -1; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3764):return (pn_type_t) > -1; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(32): > pn_dispatcher_t *disp = (pn_dispatcher_t *) calloc(sizeof(pn_dispatcher_t), > 1); // explicit cast > C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(47): disp->output > = (char *) malloc(disp->capacity); // explicit > cast > C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(248): > disp->output = (char *) realloc(disp->output, disp->capacity);// > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(193): pn_listener_t *l = > (pn_listener_t *) malloc(sizeof(pn_listener_t));// > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(410): pn_connector_t *c = > (pn_connector_t *) malloc(sizeof(pn_connector_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(656): pn_driver_t *d = > (pn_driver_t *) malloc(sizeof(pn_driver_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(748):d->fds = (pollfd *) > realloc(d->fds, d->capacity*sizeof(struct pollfd)); // explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(47): db->deliveries = > (pn_delivery_state_t *) malloc(sizeof(pn_delivery_state_t) * capacity);// > explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(438): pn_connection_t > *conn = (pn_connection_t *)malloc(sizeof(pn_connection_t)); > // explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(730): pn_session_t *ssn = > (pn_session_t *) malloc(sizeof(pn_session_t)); // > explicit cast > C:\qp
[jira] [Commented] (PROTON-98) Porting Issue -- Visual Studio compiler requires explicit casts
[ https://issues.apache.org/jira/browse/PROTON-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500287#comment-13500287 ] Mary hinton commented on PROTON-98: --- This patch can also be viewed at github in branch protonWin explicit casts - Jira Proton-98 https://github.com/MaryDHinton/qpid-proton/commits/protonWin > Porting Issue -- Visual Studio compiler requires explicit casts > --- > > Key: PROTON-98 > URL: https://issues.apache.org/jira/browse/PROTON-98 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Labels: build > Attachments: explicitCasts2.patch, ExplicitCasts.patch > > > I would like to get the code changed to add explicit casts where the Visual > Studio compiler requires it. > The GNU compiler isn’t so picky, but we need the explicit casts for Visual > Studio tools. > The problem is in many of the files. > C:\qpid\qpid\proton\proton-c\src\proton.c(278): struct client_context *ctx > = (client_context *) pn_connector_context(ctor);// explicit > cast > C:\qpid\qpid\proton\proton-c\src\buffer.c(41): pn_buffer_t *buf = > (pn_buffer_t *) malloc(sizeof(pn_buffer_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\buffer.c(45): buf->bytes = capacity ? > (char *) malloc(capacity) : NULL; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(706):return (pn_type_t) > PN_ARG_ERR; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(758):return (pn_type_t) > PN_ARG_ERR; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1210):atom->u.type = > (pn_type_t) va_arg(*ap, int); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1311): char **sptr > = (char **) ptr; // explicit > cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1875): pn_data_t *data = > (pn_data_t *) malloc(sizeof(pn_data_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1878): data->nodes = > capacity ? (pn_node_t *) malloc(capacity * sizeof(pn_node_t)) : NULL; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1931): data->nodes = > (pn_node_t *) realloc(data->nodes, data->capacity * sizeof(pn_node_t)); > // explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(2151):char > **sptr = (char**) ptr; > // explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3114):return (pn_type_t) > -1; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3764):return (pn_type_t) > -1; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(32): > pn_dispatcher_t *disp = (pn_dispatcher_t *) calloc(sizeof(pn_dispatcher_t), > 1); // explicit cast > C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(47): disp->output > = (char *) malloc(disp->capacity); // explicit > cast > C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(248): > disp->output = (char *) realloc(disp->output, disp->capacity);// > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(193): pn_listener_t *l = > (pn_listener_t *) malloc(sizeof(pn_listener_t));// > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(410): pn_connector_t *c = > (pn_connector_t *) malloc(sizeof(pn_connector_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(656): pn_driver_t *d = > (pn_driver_t *) malloc(sizeof(pn_driver_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(748):d->fds = (pollfd *) > realloc(d->fds, d->capacity*sizeof(struct pollfd)); // explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(47): db->deliveries = > (pn_delivery_state_t *) malloc(sizeof(pn_delivery_state_t) * capacity);// > explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(438): pn_connection_t > *conn = (pn_connection_t *)malloc(sizeof(pn_connection_t)); > // explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(730): pn_session_
[jira] [Updated] (PROTON-124) Porting Issue -- Visual Studio requires WSAStartup() and WSACleanup() to initialize\cleanup the Windows socket dll
[ https://issues.apache.org/jira/browse/PROTON-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-124: --- Attachment: WinSockets.patch Attached file is for initialization and cleanup of the Windows socket dll. It can also be viewed here: https://github.com/MaryDHinton/qpid-proton/compare/protonWin > Porting Issue -- Visual Studio requires WSAStartup() and WSACleanup() to > initialize\cleanup the Windows socket dll > -- > > Key: PROTON-124 > URL: https://issues.apache.org/jira/browse/PROTON-124 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Attachments: WinSockets.patch > > > Put the WSAStartup code in pn_driver() and the WSACleanup() code in > pn_driver_free(). > Used a _WINDOWS macro around the Windows code. -- 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
[jira] [Updated] (PROTON-99) Porting Issue -- pn_dtag macro does not compile with Visual Studio compiler
[
https://issues.apache.org/jira/browse/PROTON-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mary hinton updated PROTON-99:
--
Attachment: pn_dtag.patch
This patch can also be viewed at github in branch protonWin
PROTON-99 changed pn_dtag macro to a function
https://github.com/MaryDHinton/qpid-proton/compare/protonWin
> Porting Issue -- pn_dtag macro does not compile with Visual Studio compiler
> ---
>
> Key: PROTON-99
> URL: https://issues.apache.org/jira/browse/PROTON-99
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Environment: Windows using Visual Studio 2010
>Reporter: Mary hinton
> Labels: build
> Attachments: pn_dtag.patch
>
>
> I would like to replace the pn_dtag macro with a function that will compile
> using either GNU or Visual Studio compilers.
> engine.h
> Replace:
> #define pn_dtag(BYTES, SIZE) ((pn_delivery_tag_t) {(SIZE), (BYTES)}
> With:
> pn_delivery_tag_t pn_dtag(const char *bytes, size_t size);
> engine.c
> Add:
> pn_delivery_tag_t pn_dtag(const char *bytes, size_t size)
> {
> pn_delivery_tag_t delivt;
> delivt.bytes = bytes;
> delivt.size = size;
> return delivt;
> }
--
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
[jira] [Commented] (PROTON-124) Porting Issue -- Visual Studio requires WSAStartup() and WSACleanup() to initialize\cleanup the Windows socket dll
[ https://issues.apache.org/jira/browse/PROTON-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13500504#comment-13500504 ] Mary hinton commented on PROTON-124: test > Porting Issue -- Visual Studio requires WSAStartup() and WSACleanup() to > initialize\cleanup the Windows socket dll > -- > > Key: PROTON-124 > URL: https://issues.apache.org/jira/browse/PROTON-124 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Attachments: WinSockets.patch > > > Put the WSAStartup code in pn_driver() and the WSACleanup() code in > pn_driver_free(). > Used a _WINDOWS macro around the Windows code. -- 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
[jira] [Updated] (PROTON-148) Porting Issue -- Visual Studio requires an explicit cast inside the resize macros
[
https://issues.apache.org/jira/browse/PROTON-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mary hinton updated PROTON-148:
---
Attachment: PN_ENSURE.patch
> Porting Issue -- Visual Studio requires an explicit cast inside the resize
> macros
> -
>
> Key: PROTON-148
> URL: https://issues.apache.org/jira/browse/PROTON-148
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Environment: WIndows using Visual Studio 2010
>Reporter: Mary hinton
> Labels: build
> Attachments: PN_ENSURE.patch
>
>
> The PN_ENSURE and PN_ENSUREZ macros do not compile using Visual Studio
> toolset.
> Suggest changing the macros to the following for both ports:
> #define PN_ENSURE(ARRAY, CAPACITY, COUNT, PNTYPE) \
> while ((CAPACITY) < (COUNT)) { \
> (CAPACITY) = (CAPACITY) ? 2 * (CAPACITY) : 16; \
> (ARRAY) = (PNTYPE) realloc((ARRAY), (CAPACITY) * sizeof (*(ARRAY))); \
> }
> #define PN_ENSUREZ(ARRAY, CAPACITY, COUNT, PNTYPE)\
> {\
> size_t _old_capacity = (CAPACITY); \
> PN_ENSURE((ARRAY), (CAPACITY), (COUNT), PNTYPE); \
> memset((ARRAY) + _old_capacity, 0, \
>sizeof(*(ARRAY))*((CAPACITY) - _old_capacity)); \
> }
--
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
[jira] [Commented] (PROTON-148) Porting Issue -- Visual Studio requires an explicit cast inside the resize macros
[
https://issues.apache.org/jira/browse/PROTON-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501294#comment-13501294
]
Mary hinton commented on PROTON-148:
Patch is attached. It can also be viewed here.
https://github.com/MaryDHinton/qpid-proton/compare/protonWin
> Porting Issue -- Visual Studio requires an explicit cast inside the resize
> macros
> -
>
> Key: PROTON-148
> URL: https://issues.apache.org/jira/browse/PROTON-148
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Environment: WIndows using Visual Studio 2010
>Reporter: Mary hinton
> Labels: build
> Attachments: PN_ENSURE.patch
>
>
> The PN_ENSURE and PN_ENSUREZ macros do not compile using Visual Studio
> toolset.
> Suggest changing the macros to the following for both ports:
> #define PN_ENSURE(ARRAY, CAPACITY, COUNT, PNTYPE) \
> while ((CAPACITY) < (COUNT)) { \
> (CAPACITY) = (CAPACITY) ? 2 * (CAPACITY) : 16; \
> (ARRAY) = (PNTYPE) realloc((ARRAY), (CAPACITY) * sizeof (*(ARRAY))); \
> }
> #define PN_ENSUREZ(ARRAY, CAPACITY, COUNT, PNTYPE)\
> {\
> size_t _old_capacity = (CAPACITY); \
> PN_ENSURE((ARRAY), (CAPACITY), (COUNT), PNTYPE); \
> memset((ARRAY) + _old_capacity, 0, \
>sizeof(*(ARRAY))*((CAPACITY) - _old_capacity)); \
> }
--
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
[jira] [Commented] (PROTON-98) Porting Issue -- Visual Studio compiler requires explicit casts
[
https://issues.apache.org/jira/browse/PROTON-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538409#comment-13538409
]
Mary hinton commented on PROTON-98:
---
It looks like the explicit casts in the attached explicitCasts2.patch in this
Jira never got added to the codebase.
Could I get them added?
Two changes.
It looks like pn_encode_value() was removed from coedc.c Also pn_queue_init()
in messenger.c needs an explicit cast.
void pn_queue_init(pn_queue_t *queue)
{
queue->capacity = 1024;
queue->window = 0;
queue->lwm = 0;
queue->hwm = 0;
queue->deliveries = calloc(queue->capacity, sizeof(pn_delivery_t *)); }
Line 86 should be
queue->deliveries = (pn_delivery_t **) calloc(queue->capacity,
sizeof(pn_delivery_t *));
Thanks,
Mary
> Porting Issue -- Visual Studio compiler requires explicit casts
> ---
>
> Key: PROTON-98
> URL: https://issues.apache.org/jira/browse/PROTON-98
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Environment: Windows using Visual Studio 2010
>Reporter: Mary hinton
> Labels: build
> Attachments: explicitCasts2.patch, ExplicitCasts.patch
>
>
> I would like to get the code changed to add explicit casts where the Visual
> Studio compiler requires it.
> The GNU compiler isn’t so picky, but we need the explicit casts for Visual
> Studio tools.
> The problem is in many of the files.
> C:\qpid\qpid\proton\proton-c\src\proton.c(278): struct client_context *ctx
> = (client_context *) pn_connector_context(ctor);// explicit
> cast
> C:\qpid\qpid\proton\proton-c\src\buffer.c(41): pn_buffer_t *buf =
> (pn_buffer_t *) malloc(sizeof(pn_buffer_t)); //
> explicit cast
> C:\qpid\qpid\proton\proton-c\src\buffer.c(45): buf->bytes = capacity ?
> (char *) malloc(capacity) : NULL; //
> explicit cast
> C:\qpid\qpid\proton\proton-c\src\codec\codec.c(706):return (pn_type_t)
> PN_ARG_ERR; //
> explicit cast
> C:\qpid\qpid\proton\proton-c\src\codec\codec.c(758):return (pn_type_t)
> PN_ARG_ERR; //
> explicit cast
> C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1210):atom->u.type =
> (pn_type_t) va_arg(*ap, int); //
> explicit cast
> C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1311): char **sptr
> = (char **) ptr; // explicit
> cast
> C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1875): pn_data_t *data =
> (pn_data_t *) malloc(sizeof(pn_data_t)); //
> explicit cast
> C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1878): data->nodes =
> capacity ? (pn_node_t *) malloc(capacity * sizeof(pn_node_t)) : NULL; //
> explicit cast
> C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1931): data->nodes =
> (pn_node_t *) realloc(data->nodes, data->capacity * sizeof(pn_node_t));
> // explicit cast
> C:\qpid\qpid\proton\proton-c\src\codec\codec.c(2151):char
> **sptr = (char**) ptr;
> // explicit cast
> C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3114):return (pn_type_t)
> -1; //
> explicit cast
> C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3764):return (pn_type_t)
> -1; //
> explicit cast
> C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(32):
> pn_dispatcher_t *disp = (pn_dispatcher_t *) calloc(sizeof(pn_dispatcher_t),
> 1); // explicit cast
> C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(47): disp->output
> = (char *) malloc(disp->capacity); // explicit
> cast
> C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(248):
> disp->output = (char *) realloc(disp->output, disp->capacity);//
> explicit cast
> C:\qpid\qpid\proton\proton-c\src\driver.c(193): pn_listener_t *l =
> (pn_listener_t *) malloc(sizeof(pn_listener_t));//
> explicit cast
> C:\qpid\qpid\proton\proton-c\src\driver.c(410): pn_connector_t *c =
> (pn_connector_t *) malloc(sizeof(pn_connector_t)); //
> explicit cast
> C:\qpid\qpid\proton\proton-c\src\driver.c(656): pn_driver_t *d =
> (pn_driver_t *) malloc(sizeof(pn_driver_t)); //
> explicit cast
> C:\qpid\qpid\proton\proton-c\src\driver.c(748):d->fds = (pollfd *)
> realloc(d->fds, d->capacity*sizeof(struct poll
[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=13539067#comment-13539067 ] 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, QPID_CLASS_EXPORT 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: # define QPID_COMMON_EXTERN QPID_EXPORT # define QPID_COMMON_CLASS_EXTERN I used QPID_PROTON_API because an example from Micorosft, used ProjectNameDLL_API. To be closer to the QPID practice, We could use: PROTON_EXPORT 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) # define QPID_COMMON_EXTERN QPID_EXPORT # define QPID_COMMON_CLASS_EXTERN QPID_CLASS_EXPORT # define QPID_COMMON_INLINE_EXTERN QPID_INLINE_EXPORT #else # define QPID_COMMON_EXTERN QPID_IMPORT # define QPID_COMMON_CLASS_EXTERN QPID_CLASS_IMPORT # define QPID_COMMON_INLINE_EXTERN QPID_INLINE_IMPORT #endif 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. e.g. 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: http://www.cmake.org/Wiki/BuildingWinDLL They used DLLDefines.h for their file, but ImportExport.h is probably better. And another from Microsoft: http://msdn.microsoft.com/en-us/library/ms235636.aspx > 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 > #el
[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=13551777#comment-13551777
]
Mary hinton commented on PROTON-68:
---
I haven’t heard anything about adding the macros needed for dll imports and
exports for a Visual Studio port.
Cliff Jensen mention using the gcc switch –fvisibility=hidden, so I looked up
what it does.
The online documentation states that this feature “can very substantially
improve linking and load times of shared object libraries, produce more
optimized code, provide near-perfect API export and prevent symbol clashes. It
is strongly recommended that you use this in any shared objects you distribute.”
Tumentation also points you to other sources
1) Ulrich Drepper’s paper:
“A good explanation of the benefits offered by ensuring ELF symbols have the
correct visibility is given by “How To Write Shared Libraries” by Ulrich
Drepper (which can be found at http://people.redhat.com/~drepper/)—however a
superior solution made possible by this option to marking things hidden when
the default is public is to make the default hidden and mark things public.
This is the norm with DLL's on Windows and with -fvisibility=hidden and
__attribute__ ((visibility("default"))) instead of __declspec(dllexport) you
get almost identical semantics with identical syntax. This is a great boon to
those working with cross-platform projects.”
“Export Control” starts on p. 17 of this paper by listing the drawbacks when
you fail to restrict the set of exported symbols.
Not restricting the set of exported symbols is the default for gcc.
2) http://gcc.gnu.org/wiki/Visibility
Visual Studio requires you to explicitly set what symbols and functions will be
exported. The gcc shared libraries for proton would also be improved if we
exported only the necessary functions and symbols, using the visibilty switch
and the necessary shared library header file.
The wiki pages has a very good example of what is needed in their Step-by-step
guide for Windows and GNU.
Here is the example listed for the header file needed:
// Generic helper definitions for shared library support
#if defined _WIN32 || defined __CYGWIN__
#define FOX_HELPER_DLL_IMPORT __declspec(dllimport)
#define FOX_HELPER_DLL_EXPORT __declspec(dllexport)
#define FOX_HELPER_DLL_LOCAL
#else
#if __GNUC__ >= 4
#define FOX_HELPER_DLL_IMPORT __attribute__ ((visibility ("default")))
#define FOX_HELPER_DLL_EXPORT __attribute__ ((visibility ("default")))
#define FOX_HELPER_DLL_LOCAL __attribute__ ((visibility ("hidden")))
#else
#define FOX_HELPER_DLL_IMPORT
#define FOX_HELPER_DLL_EXPORT
#define FOX_HELPER_DLL_LOCAL
#endif
#endif
// Now we use the generic helper definitions above to define FOX_API and
FOX_LOCAL.
// FOX_API is used for the public API symbols. It either DLL imports or DLL
exports (or does nothing for static build)
// FOX_LOCAL is used for non-api symbols.
#ifdef FOX_DLL // defined if FOX is compiled as a DLL
#ifdef FOX_DLL_EXPORTS // defined if we are building the FOX DLL (instead of
using it)
#define FOX_API FOX_HELPER_DLL_EXPORT
#else
#define FOX_API FOX_HELPER_DLL_IMPORT
#endif // FOX_DLL_EXPORTS
#define FOX_LOCAL FOX_HELPER_DLL_LOCAL
#else // FOX_DLL is not defined: this means FOX is a static lib.
#define FX_API
#define FOX_LOCAL
#endif // FOX_DLL
> 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
[jira] [Created] (PROTON-226) Porting Issue -- Heap Corruption using Visual Studio when running client/server proton in debug mode.
Mary hinton created PROTON-226: -- Summary: Porting Issue -- Heap Corruption using Visual Studio when running client/server proton in debug mode. Key: PROTON-226 URL: https://issues.apache.org/jira/browse/PROTON-226 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.4 Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Code changes for windows port were added (MinGW and Visual Studio) to the proton codebase recently. Using the new codebase and some additional changes, I ran the proton executable using the Visual Studio toolset as both a server and client. When the client exits, a Windows popup displays: "Windows has triggered a breakpoint in proton.exe. This may be due to a corruption of the heap, which indicates a bug in proton.exe or any of the DLLs it has loaded." Still tracking this problem down. -- 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
[jira] [Created] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
Mary hinton created PROTON-236: -- Summary: Porting Issue -- Visual Studio does not provide a getopt() function Key: PROTON-236 URL: https://issues.apache.org/jira/browse/PROTON-236 Project: Qpid Proton Issue Type: Improvement Components: proton-c Environment: Windows using Visual Studio 2010 Reporter: Mary hinton Fix For: 0.4 Since Visual Studio 2010 does not provide a getopt(), I used the getopt() function found in the GNU library getopt.h and getopt.c. I made a few minor changes and will attach these files to this JIRA. Besides the proton.c file, the proton project workspace for Visual Studio would need to include getopt() files. -- 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
[jira] [Updated] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-236: --- Attachment: getopt.c > Porting Issue -- Visual Studio does not provide a getopt() function > --- > > Key: PROTON-236 > URL: https://issues.apache.org/jira/browse/PROTON-236 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Fix For: 0.4 > > Attachments: getopt.c > > > Since Visual Studio 2010 does not provide a getopt(), I used the getopt() > function found in the GNU library getopt.h and getopt.c. I made a few minor > changes and will attach these files to this JIRA. > Besides the proton.c file, the proton project workspace for Visual Studio > would need to include getopt() files. -- 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
[jira] [Updated] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-236: --- Attachment: getopt.h > Porting Issue -- Visual Studio does not provide a getopt() function > --- > > Key: PROTON-236 > URL: https://issues.apache.org/jira/browse/PROTON-236 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Fix For: 0.4 > > Attachments: getopt.c, getopt.h > > > Since Visual Studio 2010 does not provide a getopt(), I used the getopt() > function found in the GNU library getopt.h and getopt.c. I made a few minor > changes and will attach these files to this JIRA. > Besides the proton.c file, the proton project workspace for Visual Studio > would need to include getopt() files. -- 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
[jira] [Commented] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13576842#comment-13576842 ] Mary hinton commented on PROTON-236: Not sure if the getopt should be included in the proton executable project or in the Visual Studio qpid-proton dll. I made a few changes in the getopt code for Visual Studio. > Porting Issue -- Visual Studio does not provide a getopt() function > --- > > Key: PROTON-236 > URL: https://issues.apache.org/jira/browse/PROTON-236 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Fix For: 0.4 > > Attachments: getopt.c, getopt.h > > > Since Visual Studio 2010 does not provide a getopt(), I used the getopt() > function found in the GNU library getopt.h and getopt.c. I made a few minor > changes and will attach these files to this JIRA. > Besides the proton.c file, the proton project workspace for Visual Studio > would need to include getopt() files. -- 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
[jira] [Updated] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-236: --- Attachment: (was: getopt.c) > Porting Issue -- Visual Studio does not provide a getopt() function > --- > > Key: PROTON-236 > URL: https://issues.apache.org/jira/browse/PROTON-236 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Fix For: 0.4 > > > Since Visual Studio 2010 does not provide a getopt(), I used the getopt() > function found in the GNU library getopt.h and getopt.c. I made a few minor > changes and will attach these files to this JIRA. > Besides the proton.c file, the proton project workspace for Visual Studio > would need to include getopt() files. -- 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
[jira] [Updated] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-236: --- Attachment: (was: getopt.h) > Porting Issue -- Visual Studio does not provide a getopt() function > --- > > Key: PROTON-236 > URL: https://issues.apache.org/jira/browse/PROTON-236 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Fix For: 0.4 > > > Since Visual Studio 2010 does not provide a getopt(), I used the getopt() > function found in the GNU library getopt.h and getopt.c. I made a few minor > changes and will attach these files to this JIRA. > Besides the proton.c file, the proton project workspace for Visual Studio > would need to include getopt() files. -- 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
[jira] [Updated] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-236: --- Attachment: getopt.c > Porting Issue -- Visual Studio does not provide a getopt() function > --- > > Key: PROTON-236 > URL: https://issues.apache.org/jira/browse/PROTON-236 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Fix For: 0.4 > > Attachments: getopt.c, getopt.h > > > Since Visual Studio 2010 does not provide a getopt(), I used the getopt() > function found in the GNU library getopt.h and getopt.c. I made a few minor > changes and will attach these files to this JIRA. > Besides the proton.c file, the proton project workspace for Visual Studio > would need to include getopt() files. -- 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
[jira] [Updated] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-236: --- Attachment: getopt.h > Porting Issue -- Visual Studio does not provide a getopt() function > --- > > Key: PROTON-236 > URL: https://issues.apache.org/jira/browse/PROTON-236 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Fix For: 0.4 > > Attachments: getopt.c, getopt.h > > > Since Visual Studio 2010 does not provide a getopt(), I used the getopt() > function found in the GNU library getopt.h and getopt.c. I made a few minor > changes and will attach these files to this JIRA. > Besides the proton.c file, the proton project workspace for Visual Studio > would need to include getopt() files. -- 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
[jira] [Commented] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[
https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13577728#comment-13577728
]
Mary hinton commented on PROTON-236:
I looked for a getopt() with a BSD license.
freegetopt-0.11.tar.gz
BSD 3-clause license ("Revised BSD License", "New BSD License", or "Modified
BSD License").
It should work fine for Windows Visual Studio.
I put getopt.h and getopt.c in the proton-c/src folder and tested it in the
proton project.
I downloaded it from:
http://sourceforge.net/projects/freegetopt/files/latest/download
> Porting Issue -- Visual Studio does not provide a getopt() function
> ---
>
> Key: PROTON-236
> URL: https://issues.apache.org/jira/browse/PROTON-236
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Environment: Windows using Visual Studio 2010
>Reporter: Mary hinton
> Fix For: 0.4
>
> Attachments: freegetopt-0.11.tar.gz, getopt.c, getopt.h
>
>
> Since Visual Studio 2010 does not provide a getopt(), I used the getopt()
> function found in the GNU library getopt.h and getopt.c. I made a few minor
> changes and will attach these files to this JIRA.
> Besides the proton.c file, the proton project workspace for Visual Studio
> would need to include getopt() files.
--
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
[jira] [Updated] (PROTON-236) Porting Issue -- Visual Studio does not provide a getopt() function
[ https://issues.apache.org/jira/browse/PROTON-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mary hinton updated PROTON-236: --- Attachment: freegetopt-0.11.tar.gz > Porting Issue -- Visual Studio does not provide a getopt() function > --- > > Key: PROTON-236 > URL: https://issues.apache.org/jira/browse/PROTON-236 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton > Fix For: 0.4 > > Attachments: freegetopt-0.11.tar.gz, getopt.c, getopt.h > > > Since Visual Studio 2010 does not provide a getopt(), I used the getopt() > function found in the GNU library getopt.h and getopt.c. I made a few minor > changes and will attach these files to this JIRA. > Besides the proton.c file, the proton project workspace for Visual Studio > would need to include getopt() files. -- 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
[jira] [Created] (PROTON-237) Porting Issue -- basename() not found in Visual Studio 2010
Mary hinton created PROTON-237:
--
Summary: Porting Issue -- basename() not found in Visual Studio
2010
Key: PROTON-237
URL: https://issues.apache.org/jira/browse/PROTON-237
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c
Environment: Windows Visual Studio 2010
Reporter: Mary hinton
Fix For: 0.4
The basename() function in proton.c is not found in Visual Studio 2010. It is
in Visual Studio 2012 when the header is included.
It is only used in a printf statement and is not needed for porting to Visual
Studio 2010:
printf("Usage: %s [-h] [-c [user[:password]@]host[:port]] [-a ] [-m
]\n", basename(argv[0]));
--
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
[jira] [Created] (PROTON-239) Porting Issue -- gethostname() is part of winsock library
Mary hinton created PROTON-239:
--
Summary: Porting Issue -- gethostname() is part of winsock library
Key: PROTON-239
URL: https://issues.apache.org/jira/browse/PROTON-239
Project: Qpid Proton
Issue Type: Improvement
Components: proton-c
Environment: Windows using Visual Studio 2010
Reporter: Mary hinton
Fix For: 0.4
In Visual Studio, gethostname() is found within the winsock library. To use it
in proton.c, we have to include the winsock header and make sure the
WSAStartup() (used to initialize the windows socket library) has already been
called by pn_driver().
I was wondering if we could isolate the winsock header so that it is only
included in driver.c.
We could set up a new function in driver.c called pn_gethostname() whose only
function is to call gethostname().
int pn_gethostname(char *name, int namelen)
{
return gethostname(name, namelen);
}
--
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
[jira] [Commented] (PROTON-238) Initial CTest support
[ https://issues.apache.org/jira/browse/PROTON-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13578572#comment-13578572 ] Mary hinton commented on PROTON-238: This will be a nice feature. Visual Studio doesn't use make. I think we could substitute the devenv (IDE) command line for make. e.g. devenv proton.sln /Build "Debug" That might help automate it for Visual Studio. > Initial CTest support > - > > Key: PROTON-238 > URL: https://issues.apache.org/jira/browse/PROTON-238 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.3 > Environment: Mainly proton-c and interop testing. >Reporter: Cliff Jansen >Assignee: Cliff Jansen > > This is a proposal for starting to use CMake's built in CTest capabilities in > order to allow a unified test mechanism on multiple platforms. > For the supplied review patch, it assumes that instead of using > trunk/config.sh and calling proton-test directly, you do: > cd path/to/trunk > mkdir build > cd build > cmake .. > make > ctest > Assuming the make succeeds, this will test two targets for now (proton-c and > proton-jni), but the newer proposed tests (i.e. performance) can be added as > well. > Once the desired work flow is captured, this can be tweaked to run in a > platform neutral way. CMake even has the capability to run CTest from inside > the Visual Studio IDE. Concepts and strategies are stolen from the qpid/cpp > tree. > By default, you just get a brief summary of the tests. Also try > ctest -V [ to see the full output ] > ctest -N [ to list the available tests ] > ctest -R proton-c [ just run the one test in this case, or a regexp if > supplied ] > ctest -E [ run all tests except ones that match regexp ] > Fancier tests can use cmake scripts to do things in a platform neutral manner > (move files around), run the test from a different directory, etc. Python > scripts and Java programs are already platform neutral, so there is no need > to make changes for those. > Tests can be conditionally configured (in the example proton-jni will not be > configured if maven or java aren't found). > Note that if you wish to just build and test proton-c, there is no > requirement to build from within the specific directory .../trunk/build. > This restriction currently exists for testing proton-jni using maven, but > perhaps that can be relaxed in future. -- 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
