Move QgsRasterMinMaxOrigin enums to Qgis, promote to enum class

[nyalldawson]

No description provided.

[github-actions]

🪟 Windows builds

Download Windows builds of this PR for testing.
Debug symbols for this build are available here.
(Built from commit 648d53d)

🪟 Windows Qt6 builds

Download Windows Qt6 builds of this PR for testing.
(Built from commit 648d53d)

[ptitjano]

This looks good to me.

[rouault]

This has perhaps be discussed before, but shouldn't we feel concerned that qgis.h has become a 6700 lines monster that gets parsed again and again for all QGIS .cpp files ... ? Perhaps that's neglectable compared to other mandatory Qt headers ?

[nyalldawson]

This has perhaps be discussed before, but shouldn't we feel concerned that qgis.h has become a 6700 lines monster that gets parsed again and again for all QGIS .cpp files ... ?

Is it that problematic though? The bulk of the header is documentation or trivial enum declarations.

The intention here was to move enums (which are rarely changed) to a place that doesn't change much, so that we can change more headers to forward declare and ultimately make recompilation quicker. It's certainly much faster nowadays to recompile after a change to eg QgsMapLayer, where a few years ago this would have triggered an almost-full recompilation.

We're still in an in-between state though, because qgis.h ends up being changed semi regularly as we slowly move more enums into it. Over time this should slow (and eventually stop), and then it'll only be very rarely touched.

Perhaps that's neglectable compared to other mandatory Qt headers ?

QNamespace is around 2000, qstring 2000, qvariant 1000, qglobal around 1000. It certainly adds up... 🤪

[rouault]

doing some homework, creating a test program that just includes qgis.h,

on ubuntu 22.04:

# time g++  -fPIC -c ../src/core/qgis_light.cpp -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_64-linux-gnu/qt5 -Isrc/core
real	0m0.978s

# time clang++  -fPIC -c ../src/core/qgis_light.cpp -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_64-linux-gnu/qt5 -Isrc/core
real	0m1.010s

on fedora:rawhide:

# time g++  -fPIC -c ../src/core/qgis_light.cpp -I/usr/include/qt6/QtCore -I/usr/include/qt6 -Isrc/core
real	0m1.497s

# time clang++  -fPIC -c ../src/core/qgis_light.cpp -I/usr/include/qt6/QtCore -I/usr/include/qt6 -Isrc/core 2>&1 | grep open | wc -l
0
real	0m2.214s

This isn't due to the content we've added, which accounts for about 200 ms of the total time. The main culprit is just including QMetaEnum

But with precompiled headers:

on ubuntu 22.04:

# g++ -fPIC -c  ../src/core/qgis.h  -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_64-linux-gnu/qt5 -Isrc/core
# time g++  -fPIC -c ../src/core/qgis_light.cpp -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I/usr/include/x86_64-linux-gnu/qt5 -Isrc/core
real	0m0.176s

and on fedora:rawhide:

# g++   -fPIC -c ../src/core/qgis.h  -I/usr/include/qt6/QtCore -I/usr/include/qt6 -Isrc/core
# time g++  -fPIC -c ../src/core/qgis_light.cpp -I/usr/include/qt6/QtCore -I/usr/include/qt6 -Isrc/core
real	0m0.228s

So there would be some value in having a precompiler header for qgis.h

[nyalldawson]

@rouault

Interesting!

So what's your conclusion? Should we continue these cleanups for now?

[rouault]

So what's your conclusion? Should we continue these cleanups for now?

Yes. We have other options to optimize build times