On Thu, Feb 7, 2013 at 6:05 PM, Andreas Pakulat <span dir="ltr"><<a href="mailto:apaku@gmx.de" target="_blank">apaku@gmx.de</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi,<br>
<div class="im"><br>
On Thu, Feb 7, 2013 at 4:27 PM, Aleix Pol <<a href="mailto:aleixpol@kde.org">aleixpol@kde.org</a>> wrote:<br>
> On Thu, Feb 7, 2013 at 3:30 PM, Andreas Pakulat <<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> just happened to see<br>
>><br>
>> <a href="http://quickgit.kde.org/?p=kdevelop.git&a=commit&h=15bee005db20b380c0b4335d03afb0f17a4e750c" target="_blank">http://quickgit.kde.org/?p=kdevelop.git&a=commit&h=15bee005db20b380c0b4335d03afb0f17a4e750c</a><br>


>> on irc and I think the fix is wrong. CMake files do not have an<br>
>> encoding specification, so either cmake dictates an encoding in its<br>
>> documentation (or its own parser) or it does not. In the latter case a<br>
>> user needs to be able to decide which encoding to use for parsing<br>
>> cmake files, just using his local 8 bit encoding can be wrong as well.<br>
>> In particular for utf16 files or for people regularly working with two<br>
>> different encoding (thats the case a lot in asia). It also can already<br>
>> break on windows with utf-8 encoded cmake files, since the local 8 bit<br>
>> encoding there is latin1.<br>
><br>
</div><div class="im">> Well, it will be broken either way, because we're assuming latin1 anyway.<br>
> Right now, locally it works the same way at least in my system, so it maps<br>
> better how cmake works.<br>
<br>
</div>Actually thats not at all how cmake works as far as I can see. What<br>
exactly didn't work that started to work after this change?<br>
<br>
I'm wondering because as far as I see CMake is completely ignoring any<br>
file-encoding, it works solely on the files as bytes. This is also<br>
just fine, since the CMake language only has ascii characters in its<br>
identifiers and tokens. So the only thing where non-ascii characters<br>
can show up is in literal strings or in data read into cmake through<br>
the file-command and similar. In the latter case cmake again doesn't<br>
need to care, applying a regex will be done against the bytes of the<br>
read file content and hence require the cmakelists file and the file<br>
being read have the same encoding (or both using ascii only). And if<br>
literal strings are using non-ascii characters, then the behaviour is<br>
more or less undefined. If they're printed cmake simply prints the<br>
bytes which results in garbage output when run in a terminal that uses<br>
a different encoding. And if they're set to be passed to compiler<br>
commandline you're again passing bytes to that and the result will<br>
again depend on your local locale.<br>
<br>
Unfortunately we can't do that, since all our API requires QString<br>
which has a defined encoding and hence input needs to be converted to<br>
it correctly.<br>
<br>
So with all that said, I think local8bit is actually the right thing<br>
here, people running a latin1 environment and having utf-8 encoded<br>
cmake files with non-ascii characters should be getting problems with<br>
that on a commandline as well.<br>
<br>
Just use the attached (latin1-encoded) CMake file and run cmake on it<br>
in a utf-8 environment.<br>
<span class="HOEnZb"><font color="#888888"><br>
Andreas<br>
</font></span></blockquote></div><br><div>What works now is that:</div><div>add_subdirectory(blàh)</div><div><br></div><div>will match the actual directory now, in a UTF-8 system, producing a valid project tree.</div><div>

<br></div><div>Aleix</div>