On 5/25/12 9:37 AM, "ext Thiago Macieira" <thiago.macie...@intel.com> wrote:
>On sexta-feira, 25 de maio de 2012 06.27.05, lars.kn...@nokia.com wrote: >> On 5/24/12 11:38 PM, "ext Thiago Macieira" <thiago.macie...@intel.com> >> >> wrote: >> >On quinta-feira, 24 de maio de 2012 13.15.16, 1+1=2 wrote: >> >> If we want to bootstrap tool such as qmake support utf8 >> > >> >Why would we want to? >> >> One reason could be paths/filenames that are encoded in the .pro file. >>If >> we interpret it as latin1, we can't support international filenames. > >If we are reading the .pro file as Latin 1 and we encode the filenames as >Latin >1 when calling the POSIX functions, it will work just fine. So I don't >see a >problem on Linux. You're right, since toLocal8Bit() is equivalent to toLatin1() in bootstrap mode. >As for Windows, writing an 8-bit path is a mess anyway. Is the .pro file >supposed to be encoded in UTF-8 or in the Windows legacy ANSI encoding? Yeah, this is somewhat messy, as the Win32 APIs take wchar's (ie. utf16). >> And we are now assuming utf8 for all our C++ and QML source code. One >> could argue that assuming the same encoding for .pro files would be only >> consistent. > >I agree: we'd assume that the encoding of the .pro file is UTF-8. > >However, at this point I'd simply recommend ignoring the problem. Let's >not >try and modify qmake any than we really must for getting 5.0 out. Ok, agree with that. It's certainly not worse in 5.0 than it has been for years :) Cheers, Lars _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
