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

Roger Leigh commented on XERCESC-2132:
--------------------------------------

See attached patches or 
[https://github.com/apache/xerces-c/compare/trunk...rleigh-codelibre:xmlch-option?expand=1]

cmake: Add \{-Dxmlch-type=(char16_t|uint16_t|wchar_t)} option

autoconf: Add \{--enable-xmlch-(char16_t|uint16_t|wchar_t)} option

 

This doesn't change the pre-existing behaviour; the fallback order is still the 
same, but it will allow the user to override this to choose a specific type.

 

I'll do some more testing to ensure the fallbacks are correct in all cases.  
Any feedback would be appreciated.

> cmake: Add the ability to force the specific XMLCh type to use
> --------------------------------------------------------------
>
>                 Key: XERCESC-2132
>                 URL: https://issues.apache.org/jira/browse/XERCESC-2132
>             Project: Xerces-C++
>          Issue Type: Improvement
>          Components: Build
>    Affects Versions: 3.2.0
>            Reporter: Roger Leigh
>            Assignee: Roger Leigh
>            Priority: Major
>
> Currently the CMake build default to a 16-bit integer type.  It will use 
> char16_t where available, and fall back to wchar_t on Windows when available. 
>  This means that old Visual Studio versions will use wchar_t while newer ones 
> use char16_t, but there are cases where selection of a specific XMLCh type is 
> desirable, to force the use of wchar_t e.g. for compatibility reasons.
>  
> Add an option to select a specific XMLCh type, overriding the default checks 
> and fallbacks.
>  
> Also, check that the autotools build behaves the same way.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org

Reply via email to