[CMake] Bug #12189

David Cole david.cole at kitware.com
Wed Aug 31 12:01:46 EDT 2011


Your patch has the "wrong sense" I think.... It looks like it's
removing "_SBCS" code, but you want to add all that code, correct?

I think (as long as my above assumption is correct) that this patch
should be ok, even in a backwards compatibility sense, because only
people who have "_SBCS" defined as a target property compile
definition will have code generated differently than before.

And I suspect your the only person in the world at this point for whom
this is true. :-)

Of course, to accept it into CMake, it would be nice to have it
documented somewhere, and to have a test that exercises the newly
added code. Especially now that we've entered the release candidate
phase of 2.8.6.

Any chance you can add a test (or modify an existing one) to add the
_SBCS compile definition as a target property?


On Wed, Aug 31, 2011 at 11:38 AM,  <aaron.meadows at thomsonreuters.com> wrote:
> Any of you CMakers want to comment on this bug and patch?  I’d like to be
> able to switch my company back to the public version of CMake instead of
> compiling my own flavor every time there is a release…
>
>
>
>
>
> Aaron Meadows
>
>
>
> From: Meadows, Aaron C.
> Sent: Thursday, June 23, 2011 2:23 PM
>
> To: Meadows, Aaron C.; 'cmake at cmake.org'
> Subject: RE: [CMake] Bug #12189
>
>
>
> I’ve updated the bug with an additional patch (had a  bug for some
> configuration cases).
>
>
>
> What is the procedure to get this patch considered and applied?  Do I need
> to contact the Visual Studio Generator maintainer directly?
>
>
>
> Aaron C. Meadows
>
> From: Meadows, Aaron C.
> Sent: Tuesday, June 21, 2011 9:49 AM
> To: Meadows, Aaron C.; cmake at cmake.org
> Subject: RE: [CMake] Bug #12189
>
>
>
> I updated the bug with this patch and some of the details from below.
>
>
>
> Aaron C. Meadows
>
> From: cmake-bounces at cmake.org [mailto:cmake-bounces at cmake.org] On Behalf Of
> Meadows, Aaron C.
> Sent: Monday, June 20, 2011 5:17 PM
> To: cmake at cmake.org
> Subject: [CMake] Bug #12189
>
>
>
> (link: http://public.kitware.com/Bug/view.php?id=12189)
>
>
>
> I just came across the above bug opened last month,  Summaraized as: “It is
> not possible to generate a Visual Studio project with ASCII/SBCS character
> set”.  (Full Bug Text Following Message)
>
>
>
> I find myself in the situation where I need this to be set to “not set”, so
> as to have ASCII/SBCS as the character set for all my projects.  I dug back
> through the last few years of the maillist and didn’t see anything about
> this issue.
>
>
>
> Anyone have experience with this issue?  And better yet, know of a solution?
>
>
>
> I checked the source file he indicated (it’s on line 702 of the 2.8.4
> source):
>
>   // If unicode is enabled change the character set to unicode, if not
>
>   // then default to MBCS.
>
>   if(targetOptions.UsingUnicode())
>
>     {
>
>     fout << "\t\t\tCharacterSet=\"1\">\n";
>
>     }
>
>   else
>
>     {
>
>     fout << "\t\t\tCharacterSet=\"2\">\n";
>
>     }
>
>
>
> Additionally, VS 2010 has a different mechanism (line 287 of the 2.8.4
> source):
>
>     if(this->Target->GetType() <= cmTarget::MODULE_LIBRARY &&
>
>        this->ClOptions[*i]->UsingUnicode())
>
>       {
>
>       this->WriteString("<CharacterSet>Unicode</CharacterSet>\n", 2);
>
>       }
>
>     else
>
>       {
>
>       this->WriteString("<CharacterSet>MultiByte</CharacterSet>\n", 2);
>
>       }
>
>
>
> In the case of VS 2010, the proper ASCII setting is:
>
>        <CharacterSet>NotSet</CharacterSet>
>
>
>
>
>
> It would be fairly trivial to change both these cases to generate the “Not
> Set” case.  However, how should backward compatibility be maintained, if at
> all?
>
>
>
> I’ve created and attached a patch which resolves this bug by adding an
> “_SBCS” define which is checked.  If it is set and “_UNICODE” is not set, it
> will write the correct files for the “Not Set” ASCII case.  This is slightly
> different than the suggestion in the Bug, but was very easy to write and
> provides identical behavior if “_SBCS” is not set.
>
>
>
>
>
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Full Bug Text:
>
> ----------------------------------------------------------------------------------------------------------------------------------
>
> In Visual Studio 9.0 (and prior, 10.0 i don't know) it is possible specify
> three different character sets for your project within the project
> properties:
>
> Not Set = ASCII/SBCS (Single Byte Character Set)
> Unicode
> Multi-Byte
>
> Depending on the option different preprocessor defines are set
> (http://msdn.microsoft.com/en-us/library/c426s321(v=vs.80).aspx [^]):
>
> SBCS: neither _UNICODE nor _MBCS defined
> Unicode: _UNICODE defined
> Multi_Byte: _MBCS defined
>
> The character set settings is stored within the vs proj files as an xml
> attribute:
>
> SBCS: CharacterSet="0"
> Unicode: CharacterSet="1"
> Multi-Byte: CharacterSet="2"
>
> However, the cmake visual studio generators do not support generating of
> projects with CharacterSet="0" (see cmLocalVisualStudio7Generator.cxx line
> 730). At the moment the generators select unicode if a _UNICODE macro has
> been set by add_definitions, otherwise multi-byte is selected.
>
> To solve the problem and to keep backwards compatability, i suggest to
> define the _MBCS macro by default for the visual studio generators and to
> set CharacterSet="2" only if this macro is still available and otherwise
> CharacterSet="0". In that case the user can remove the _MBCS macro by
> remove_definitions and select this way the SBCS. If the user adds _UNICODE
> by add_definitions CharacterSet="1" should be selected and the conflicting
> _MBCS macro must be deleted by the code generator.
>
> ----------------------------------------------------------------------------------------------------------------------------------
>
>
>
> Aaron Meadows
> Software Engineer
>
> Thomson Reuters
>
> Phone: 314.468.3530
> Mobile: 636.541.6139
> aaron.meadows at thomsonreuters.com
> thomsonreuters.com
>
> This email was sent to you by Thomson Reuters, the global news and
> information company. Any views expressed in this message are those of the
> individual sender, except where the sender specifically states them to be
> the views of Thomson Reuters.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>


More information about the CMake mailing list