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, <[email protected]> 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.; '[email protected]' > 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.; [email protected] > Subject: RE: [CMake] Bug #12189 > > > > I updated the bug with this patch and some of the details from below. > > > > Aaron C. Meadows > > From: [email protected] [mailto:[email protected]] On Behalf Of > Meadows, Aaron C. > Sent: Monday, June 20, 2011 5:17 PM > To: [email protected] > 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 > [email protected] > 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 > _______________________________________________ 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
