[Development] INTEGRITY

[Tuukka Turunen]

Hi Marc,

A lot of the Qt functionality works perfectly well on INTEGRITY. Even the advanced graphics such as Qt Quick, Qt 3D and Qt 3D Studio. I do not see it reasonable to claim that it is "so far behind all the other supported platforms, as well as its own claim of conformance, that the question must be asked why it's still supported". Like any RTOS platform, there are known restrictions in the functionality supported on INTEGRITY: https://doc.qt.io/qt-5/integrity.html. If there are additional restrictions, those should be added to the platform notes. There also may be work arounds needed for some items, as suggested. In case of issues with the OS or the compiler, it is also possible to report a bug to Green Hills. 

Yours,

	Tuukka


On 19/09/2019, 12.21, "Development on behalf of Mutz, Marc via Development" <development-bounces at qt-project.org on behalf of development at qt-project.org> wrote:

    On 2019-09-19 10:56, Lars Knoll wrote:
    >> 4. drop Integrity support (or update to a newer version) ASAP (for
    >> Qt 5.15 if not 5.14).
    > 
    >  This is a bit black and white. You’re proposing to drop all of
    > INTEGRITY because you’re not willing to work around things on that
    > platform for one patch that is in principle a pure cleanup patch doing
    > internal refactoring. It wouldn’t be too difficult (though maybe not
    > very nice looking though) to keep the old code for INTEGRITY only.
    > It’s been tested and we know it works.
    > 
    > We’ve been applying workarounds for missing support for some C++11
    > features in other toolchains/compilers as well. We kept the Atomic
    > implementations for MSVC around for exactly the same reasons.
    
    That may work for the series of patches that implements QWaitCondition 
    using std::condition_variable, which, indeed, is just a cleanup patch.
    
    But it helps nothing with all the places where we use QWaitCondition in 
    Qt implementation and would like to replace it with 
    std::condition_variable + std::mutex, because, as I explained in an 
    earlier mail, QWaitCondition is a condition_variabe_any and thus has 
    inherently and unavoidably more overhead than condition_variable + 
    mutex. There is no justification to add #ifdefs for all the places that 
    QWaitCondition is used unconditionally now, so either we don't get the 
    order-of-magnitude improvement on our main platform, Windows, or we need 
    to introduce a private QtPrivate::condition_variable as an inline 
    wrapper around condition_variable + mutex or, for Integrity, 
    QWaitCondition + QMutex, which we need to replace once more with 
    std::condition_variable + mutex if Integrity is fixed. Is it worth it, 
    for a buggy platform that's in the process of being fixed? I'm not sure 
    it would be...
    
    In addition, as Peppe noticed, this is not the first time Integrity has 
    shown up as a problematic platform, and it now is so far behind all the 
    other supported platforms, as well as its own claim of conformance, that 
    the question must be asked why it's still supported.
    
    Thanks,
    Marc
    _______________________________________________
    Development mailing list
    Development at qt-project.org
    https://lists.qt-project.org/listinfo/development