Windows cross build

[Tomaz Canabrava]

On Monday 07 October 2013 16:04:03 Lubomir I. Ivanov wrote:
> On 7 October 2013 09:26, Thiago Macieira <thiago at macieira.org> 
wrote:
> > On segunda-feira, 7 de outubro de 2013 04:06:45, Hohndel, Dirk 
wrote:
> >> Lubomir
> >> 
> >> removing the glib dependency took away the helper functions 
that you
> >> used in windows.c to address the command line argument 
problem.
> >> 
> >> Can you look at ways to do this without glib?
> 
> i'm guessing our goal is still to parse the UTF-16 argument list on
> windows, but the question here is do we still need to convert it to
> UTF-8 given QString uses UTF-16 internally?
> 
> looking at main.cpp, what happens currently is:
> subsurface_command_line_init(&argc, &argv); // would convert
> UTF16->UTF8 with wildcard expansion
> init_ui(&argc, &argv); // these are now UTF-8 arguments and we 
pass
> them to QApplication.
> ...
> importedFiles.push_back( QString(a) ); // which i don't think will
> work without ::fromUtf8() for 'a'?
> // so perhaps the list should be obtained with
> QCoreApplication::arguments() here?
> 
> attached zip is a working example of how it's done with WINAPI calls 
only.
> if Thiago has any objections against this technique we can follow 
another
> path.
> > Qt provides a Windows command-line parser too. And if we switch 
to qmake,
> > it will be added too (it's a small static library).
> > 
> >> I just pushed a commit to master that allows me to cross build 
for
> >> Windows again, but I had to disable the utf8/utf16 code for that.
> > 
> > However, the qtmain parser does not handle filenames that can't 
be
> > represented on the Windows "ANSI" encoding. That requires 
writing Win32
> > code.
> > 
> > It's something I need to fix for Qt 5, but it's not very easy.
> 
> i tested my code using Qt5.0 with mingw-gcc-4.7.2 (sjlj), and it's
> mainly based around __wgetmainargs() and WideCharToMultiByte().
> i've just read that someone has submitted a new class for Qt 5.2 
that
> handles the windows argument list correctly, but i lost the link.
> 
> problem here is that we are still using Qt4.x and i think that
> including this solution would be more portable at least for the
> moment.

The port to Qt5 won't take long, the marble team is working to make it 
compile on Qt5. I think we will release a 4.0 version and a tiny bit after, 
a 4.1 or 4.2 that uses Qt5 ( maybe a 5.0? )

> also, i could be doing something wrong, but it seems that Qt5
> QApplication does not handle wildcard expansion, for lines such as:
> ./subsurface ./*.xml ./*.csv
> 
> lubomir
> --