Hi, sorry for a somewhat bitter tone, I find it a bit hard to avoid(*):
On Sat, 5 Mar 2016 11:37:48 +0100 Allan Sandfeld Jensen <k...@carewolf.com> wrote: > On Saturday 05 March 2016, Thomas Lübking wrote: > > On Samstag, 5. März 2016 08:09:22 CEST, Thomas Friedrichsmeier > > wrote: > > > QtWebEngine can _only_ be compiled using (free > > > as in beer) MSVC 2013. In particular, MinGW is explicitly _not_ > > > supported. > > > > Out of pure curiosity: got details on this? > > MSVC 2013 hardly supersets the GNU toolchain and the code cannot > > make use of MSVC's "let's try to compile this junk, despite it's > > not nearly valid c++" features, because it generally still needs to > > compile on other systems. > > > Chromium doesn't support it, and generally we try to stick to the > same platforms Chromium support. We haven't actually investigated how > much work it would be to make it work. I think making a credible effort in that direction is really the _least_ thing you can and should do. I do understand your whole idea is to get by with fewer (or no) patches(**). And I understand you are not particularly keen to even think about introducing a significant patch-set, when you have long since committed to QtWebEngine. But that strategy simply carries a cost, and I'm not quite sure that this is well-understood, yet. As things stand, I think you are effectively phasing out MinGW-support, and to be honest, my impression is that you have not been terribly upfront about it, so far. Regards Thomas --- (*) So, some background, in case anyone is interested: My application needs an internal HTML-browser for several purposes. It also interfaces with MinGW-only library / environment. (Why not try to support MSVC for that library, I hear you ask? Because it has literally 8000+ add-on packages, not all of which are cross-platform, not all of which contain compiled code, but thousands of which are distributed as - MinGW-compiled - binaries.) I am lucky on two counts, here: First, I don't need to display any remote HTML, and so I can get by using QtWebKit for now. But the time will come when some of the add-ons start relying on browser features that are not supported by QtWebKit, or some third application/framework, that I'd like to interface with, will hard-depend on QtWebEngine. Second, I am interfacing with a C-only API, and so I can (sort of) get along with MSVC. But there are more subtleties in mixing the two compilers than an incompatible C++-ABI, and these are no-fun at all to debug. As one example, it took me almost an entire day to debug a (deterministic!) crash, when the MinGW-library was trying to free a pointer that I had to allocate myself (with MSVC). Getting lucky, again, I did find a way to hack around this. But there are more, non-derministic issues that appear to be unique to the MSVC-build. (**) On the other hand, at least these patches would not be Qt-specific. Even if they won't be upstreamed, I imagine you could count on a least some community support in maintaining them.
pgpop31tLWwA3.pgp
Description: OpenPGP digital signature
