Menu

#32 Qt 5.10 support with Visual Studio 2017

Unstable_(example)
open
Qt5_10 (1)
5
2019-05-31
2018-02-05
Eelco@Peacs
No

I am currently upgrading my source tree to enable Qt 5.10 with Visual Studio 2017. I also disabled use of deprecated Qt functioanlity. This resulted in some compiler warnings, one due to deprecated code (qsort) and one for changed function name (QDateTime::created()).

Regarding the qsort function, I don't really now in what version of Qt this has been deprecated, but I added a test for Qt version 5.2.

In the test project file some changes were required for the QT Test library support.

Also one optional change have been added to both project files. You can use zlib library though the Qt core library. The zlib API functions are exposed through the qtcore DLL so no need to download a seperate zlib source tree. Yes, but in stead you need the complete Qt source tree, so it should be a choice to use this option or not. Might be something to encapsulate in a separate CONFIG(USE_QT_ZLIB) test.

1 Attachments

Discussion

  • Eelco@Peacs

    Eelco@Peacs - 2018-02-07

    Sometimes a rebuild all does bring up some more issues to fix, sorry. Attached a new version of the patch with included now some changes do to the depricated use of Q_FOREACH. This has been depricated since Qt 5.7, so I added the pre-compiler check

     
  • Sergey A. Tachenov

    Looking at this patch, I'm not sure whether it's worth the trade-off. All those checks really clutter the code and smell like macro abuse. As for using the bundled zlib, it's a really old idea, which may or may not be useful depending on the environment, so I'd rather leave it up to the user to provide all the necessary INCLUDEPATH and LIBS parameters on per-machine basis. And is it really that important to get rid of the deprecated functionality? I'd rather have it there than to have all those checks. And I do need to support legacy code with Qt as far back as 4.6. And I believe that for statement is a C++11 feature, which is again maybe unavailable on legacy systems. So as long as deprecated code doesn't break anything and resulsts in just some warnings, I'd rather keep it as it is.

     
  • Eelco@Peacs

    Eelco@Peacs - 2018-02-26

    Valid conclusion and for most of the obsolete functions, being required to keep them backward compatible, it is best to keep it in. So when I re-enable obsolete functions into my project, most issues get resolved and all will function until there will be a real breach in upcoming version of Qt. Which might take still a long time for Qt needs to be compatible as well.
    One issue though remains and that is for the use of the Q_FOREACH macro in JlCompress.cpp. I use a third-party library that has been built as of Visual Studio 2015 and uses the more modern STL functions provided as of this release. This STL functionality now conflicts with the provided Qt foreach functions. To prevent this I had to disable the Qt foreach function by defining DEFINES += QT_NO_FOREACH to my project file which made the Q_FOREACH macro not being defined. Thus preventing compilation.
    So I would like to suggest a rather painless change to this part of the code by writing it as a normal C++ for-loop instead of using the Q_FOREACH macro. See attached patch.

     
  • Eelco@Peacs

    Eelco@Peacs - 2019-05-31

    Thanks for incorporating the patch into the development trunk. I tested it and it work fine. Great.

    Already a date for the new 0.7.4. release so we can tye our software to a released version?

     
  • Eelco@Peacs

    Eelco@Peacs - 2019-05-31

    Just found that the project has been moved to GitHub with even newer releases.