[Releasing] qtwebkit 5.5.2 or 5.6.0

[Thiago Macieira]

On Wednesday 02 December 2015 12:11:04 Oswald Buddenhagen wrote:
> it sort of makes sense to put it into qmake (the minimal syncqt needed
> to bootstrap qmake can be easily re-implemented with sh and cmd).
> what i don't like about this is that this is rather heavily qt-specific,
> so it's a bit ugly to put it into the more or less generic code in
> qmake. ah, well ...

It's not like qmake is agnostic of Qt... it has quite a few Qt'isms there. And 
people who do CONFIG -= qt know that there may be dragons, since we don't 
really test that.

> i've also considered rewriting it in the qmake language, but it would be
> really abysmally slow.
> 
> a middle ground may be exposing a parametrizable "c++ preprocessor and
> parser kernel" which would be used also by the dependency and automoc
> scanners. eddy had "fun" with this code just recently. how's that for a
> project?  ^^

Indeed, that would be nice.

> > Given that it is going to open files and all the Unicode issues on
> > Windows, I think the latter is the better way forward.
> 
> qmake just uses latin1 (windows) or 8-bit pass-through (unix) anyway.
> but that has never been a serious problem for qt itself.
> let me also remind you of https://bugreports.qt.io/browse/QTBUG-27896 ;)

Important, but orthogonal issue. The point is that qmake needs to be able to 
work when Qt sources or build target are on a path that contains non-local8bit 
characters on Windows. I don't know if that works now, but I'd rather we 
didn't make things worse.

I think the MinGW runtime library has a function that allows you to set the 
encoding of filenames in the API to UTF-8 (I think we used it in Subsurface), 
but I'd be surprised if the same function exists on MSVC.

> note that there is another problem in the way of shipping git archives
> as distributables: configure.exe.

Why?

> at a minimum, the help content needs to be extracted into a static .txt
> file, so configure.bat can just dump it when it's called with /help.

Oh. Yeah, people complained that configure -help started building stuff. We can 
have a minimal help that says that the full help requires building configure 
first. This minimal output wouldn't need to be maintained per platform, it 
would be just the immutable basics.

> then it will be ok to always bootstrap configure.exe.
> the help output of the unix configure is mostly static already, so
> it should be fairly easy to unify it.

The problem is that the configures take different options. There are switches 
that exist only for Unix and not for configure.exe. Unifying the switches is 
more work that we don't need now.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center