From gdt at lexort.com Sun Nov 2 07:44:47 2025 From: gdt at lexort.com (Greg Troxel) Date: Sun, 02 Nov 2025 10:44:47 -0500 Subject: [QGIS-Developer] Status of 3.44 becoming LTR? Message-ID: I saw 3.40.12 and updated pkgsrc, and the .12 being pretty high made me guess that there was a new LTR and I should look at it. I went to read https://qgis.org/resources/roadmap/ and after staring at it for a long time, my take is: - 3.44 is *going to be* LTR, but will not be blessed as such until 3.44.8 in February - What is unusual is that LTR will be 3.44.8, not 3.46.4, because there was no 3.46 in 2025-10, but we're still holding off until February, because some blend of + LTR promotion is always February + LTR promotion of a future-LTR happens only when the next branch .0 comes out. - 4.2 will become LTR in 2026-10, which is out of cycle, and probably we'll then see 4.8 in 2027-10 with LTRs happening on October instead of February. (That's an observation not a complaint.) If I'm confused a clue would be appreciated, and if 99.9% of the list was already super clear sorry for the noise. Separately, given that pkgsrc is on the fence between "latest release is fine" and "LTR is more stable and better", I should be planning to switch from 3.40.x to 3.44.x, and any time between now and just after the LTR-blessing of 3.44 on 2026-02-20 is a reasonable time to do that. (I am building 3.44.4 from source and it's halfway through.) My impression is that 3.44 is entirely stable and that for normal users (not trying to coordinate with other packaging systems in big organizations, and not having the LTS "running old code on purpose is good" outlook), there is no real reason to stay on 3.40. It is clear that I should try to package 4.0, or even 3.99, but as a separate/experimental package, to surface and resolve qt6 issues. From clhermansen at gmail.com Sun Nov 2 08:10:12 2025 From: clhermansen at gmail.com (chris hermansen) Date: Sun, 2 Nov 2025 08:10:12 -0800 Subject: [QGIS-Developer] QGIS on Ubuntu 25.10 Message-ID: I would like to offer a big thank you for finding QGIS available on Ubuntu 25.10 this past week after belatedly upgrading. Really appreciated! Chris Hermansen ? clhermansen "at" gmail "dot" com C'est ma fa?on de parler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Mon Nov 3 05:17:21 2025 From: gdt at lexort.com (Greg Troxel) Date: Mon, 03 Nov 2025 08:17:21 -0500 Subject: [QGIS-Developer] precompiled headers, turning off Message-ID: Building 3.44 on NetBSD (using ccache in our compiler wrappers and disabled in qgis) I'm getting errors about precompiled headers: [110/5655] Building CXX object src/core/CMakeFiles/qgis_core.dir/symbology/qgssymbollayerreference.cpp.o cc1plus: warning: /tmp/work/geography/qgis/work/qgis-3.44.4/cmake-pkgsrc-build/src/core/CMakeFiles/qgis_core.dir/cmake_pch.hxx.gch: had text segment at different address >From searching, it seems that gcc pch is buggy in the presence of ASLR, and that this causes ccache not to cache. Indeed, I get repeated misses. So I tried CMAKE_CONFIGURE_ARGS+= -DUSE_PRECOMPILED_HEADERS:BOOL=FALSE which not surprisingly adds the rhs to the cmake invocation, but no change. Grepping the diff from 3.40 to 3.44 (I am ignoring 3.42 on purpose), I see $ git diff ..release-3_44 |egrep PRECOM + set(USE_PRECOMPILED_HEADERS OFF) + set(USE_PRECOMPILED_HEADERS ON) +if (USE_PRECOMPILED_HEADERS) +if (USE_PRECOMPILED_HEADERS) +if (USE_PRECOMPILED_HEADERS) +if(USE_PRECOMPILED_HEADERS) +if (USE_PRECOMPILED_HEADERS) +if (USE_PRECOMPILED_HEADERS) and I don't see an option declaration or a way for the cmake invoker to say don't do that. I'm about to patch to always OFF and will see how that goes. I wonder if people think this is a bug, and if it's turning up on other systems with ASLR, or if it's only the combination of older gcc (I'm using 10) and ASLR. (As an aside, this wasn't listed in NEWS, and I'm finding it to be a significant user-visible change, as I consider compiling from source to be a user activity for a Free Software project. I realize it was intended to be invisible, but I view pch as hairy and not normal, having started C with K&R first edition.) From julien.cabieces at oslandia.com Mon Nov 3 08:45:08 2025 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Mon, 03 Nov 2025 17:45:08 +0100 Subject: [QGIS-Developer] Dirtying project within model classes or not Message-ID: <87a513oyjv.fsf@julienlaptop.home> Hi all, I recently faced a strong disagreement about a design question that I would like to discuss so we could take a decision on what it's best to do. The discussion starts here [0] According to Nyall: "dirtying is a gui/app level operation, which should only occur as a direct result of user operations (as opposed to say a script/plugin/process calling a particular piece of API)" I strongly disagree, I think setDirty() calls should be made within model classes, not in widgets. A plugin script that would modify a model object expects the project to be dirty. If not, modifications made by the script could simply be lost when closing the project without even prompting user about unsaved modifications. In several (most?) occasions (here for instances [1], [2]) it's done in the model part, but there are actually some where it was not the case. I was considering those as issues, but it seems that we have different view on the matter. So, I'd like to know if we should: - always dirty the project within model classes - never dirty the project within model classes - it depends... Regards, Julien [0] https://github.com/qgis/QGIS/pull/63498#discussion_r2425462712 [1] https://github.com/qgis/QGIS/blob/275c7d4466f5df99f7a7467d3331ce11a7394b8d/src/core/project/qgsproject.cpp#L490 [2] https://github.com/qgis/QGIS/blob/275c7d4466f5df99f7a7467d3331ce11a7394b8d/src/core/project/qgsproject.cpp#L975 -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From gdt at lexort.com Mon Nov 3 14:54:15 2025 From: gdt at lexort.com (Greg Troxel) Date: Mon, 03 Nov 2025 17:54:15 -0500 Subject: [QGIS-Developer] precompiled headers buggy, how to disable, compilation error In-Reply-To: (Greg Troxel via's message of "Mon, 03 Nov 2025 08:17:21 -0500") References: Message-ID: This is a known problem with gcc, sort of addressed: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71934 After failing to disable pch with cmake, I edited the CMakeFiles where target_precompiled_header existed and just removed it. Building again, I don't get the warning, and things are mostly ok. One file failed to build, and after fixing it (see below), I was able to get the build to complete. My question is: Is there a way to add something to the cmake line to disable precompiled headers? (It really seems like there should be.) Greg * src/core/pal/priorityqueue.cpp I got a complaint that was likely missing. I am guessing that somehow precompiled headers include it somehow when building in that mode -- although that seems buggy. I added a patch and it built. But obviously it's building for ~everybody else. I wonder if others, if you remove the "target_precompiled_headers" line, can build this file. The patch: --- src/core/pal/priorityqueue.cpp.orig 2025-11-03 18:44:19.775172737 +0000 +++ src/core/pal/priorityqueue.cpp @@ -28,6 +28,7 @@ */ #include +#include #include "internalexception.h" #include "priorityqueue.h" The error output (without the patch): FAILED: [code=1] src/core/CMakeFiles/qgis_core.dir/pal/priorityqueue.cpp.o /tmp/work/geography/qgis/work/.cwrapper/bin/c++ -DCMAKE_SOURCE_DIR=\"/tmp/work/geography/qgis/work/qgis-3.44.4\" -DPROTOBUF_USE_DLLS -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0x050800 -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH -DQT_POSITIONING_LIB -DQT_PRINTSUPPORT_LIB -DQT_SERIALPORT_LIB -DQT_SQL_LIB -DQT_SVG_LIB -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -DSIP_VERSION=0x060c00 -DTEST_DATA_DIR=\"/tmp/work/geography/qgis/work/qgis-3.44.4/tests/testdata\" -DWITH_COPC -DWITH_EPT -D_HAVE_PTHREAD_ -Dqgis_core_EXPORTS -I/tmp/work/geography/qgis/work/qgis-3.44.4/cmake-pkgsrc-build/src/core/qgis_core_autogen/include -I/tmp/work/geography/qgis/work/qgis-3.44.4/cmake-pkgsrc-build -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/poly2tri -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/ept -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/copc -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/vpc -I/tmp/work/geography/qgis/work/qgis-3.44.4/cmake-pkgsrc-build/src/core -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/meshOptimizer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/3d -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/actions -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/annotations -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/auth -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/browser -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/callouts -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/classification -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/diagram -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/dxf -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/editform -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/effects -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/elevation -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/expression -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/externalstorage -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/fieldformatter -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/geometry -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/geocoding -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/gps -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/labeling -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/labeling/rules -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/layertree -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/layout -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/locator -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/maprenderer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/mesh -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/metadata -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/network -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/numericformats -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/painting -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pdf -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/plot -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pointcloud -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pointcloud/expression -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/processing -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/processing/models -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/proj -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/project -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/arcgis -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/memory -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/gdal -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/ogr -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/meshmemory -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/sensorthings -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/raster -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/renderer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/scalebar -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/settings -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/sensor -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/stac -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/symbology -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/textrenderer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/tiledscene -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/validity -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/vector -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/vectortile -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/web -I/tmp/work/geography/qgis/work/qgis-3.44.4/external -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/delaunator-cpp -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/kdbush/include -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/nmea -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/rtree/include -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/tinygltf -isystem /usr/pkg/qt5/include/Qca-qt5/QtCrypto -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtCore -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/./mkspecs/netbsd-g++ -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtGui -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtXml -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtWidgets -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtSvg -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtNetwork -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtSql -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtConcurrent -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtPositioning -isystem /tmp/work/geography/qgis/work/.buildlink/include/geos -isystem /usr/pkg/qt5/include -isystem /usr/pkg/qt5/include/QtDBus -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtPrintSupport -isystem /usr/pkg/include -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtSerialPort -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/python3.13 -Dz_off_t=long -I/usr/pkg/include/libxml2 -I/usr/pkg/include/minizip -I/usr/pkg/qt5/include -I/usr/pkg/include/glib-2.0 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/harfbuzz -I/usr/pkg/include/freetype2 -I/usr/X11R7/include -I/usr/X11R7/include/libdrm -I/usr/pkg/include/gstreamer-1.0 -I/usr/pkg/qwt-6.3.0/include -Wall -Wextra -Wno-long-long -Wformat-security -Wno-strict-aliasing -Wnon-virtual-dtor -Wno-redundant-move -Wno-misleading-indentation -Wno-deprecated-copy -std=gnu++17 -fPIC -fvisibility=hidden -fPIC -MD -MT src/core/CMakeFiles/qgis_core.dir/pal/priorityqueue.cpp.o -MF src/core/CMakeFiles/qgis_core.dir/pal/priorityqueue.cpp.o.d -o src/core/CMakeFiles/qgis_core.dir/pal/priorityqueue.cpp.o -c /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp In file included from /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:33: /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:96:12: error: 'unique_ptr' in namespace 'std' does not name a template type 96 | std::unique_ptr heap; | ^~~~~~~~~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:37:1: note: 'std::unique_ptr' is defined in header ''; did you forget to '#include '? 36 | #include +++ |+#include 37 | /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:97:12: error: 'unique_ptr' in namespace 'std' does not name a template type 97 | std::unique_ptr p; | ^~~~~~~~~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:97:7: note: 'std::unique_ptr' is defined in header ''; did you forget to '#include '? 97 | std::unique_ptr p; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:98:12: error: 'unique_ptr' in namespace 'std' does not name a template type 98 | std::unique_ptr pos; | ^~~~~~~~~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:98:7: note: 'std::unique_ptr' is defined in header ''; did you forget to '#include '? 98 | std::unique_ptr pos; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In constructor 'pal::PriorityQueue::PriorityQueue(int, int, bool)': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:53:3: error: 'heap' was not declared in this scope; did you mean 'upheap'? 53 | heap = std::make_unique( maxsize ); | ^~~~ | upheap /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:53:15: error: 'make_unique' is not a member of 'std' 53 | heap = std::make_unique( maxsize ); | ^~~~~~~~~~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:34:1: note: 'std::make_unique' is defined in header ''; did you forget to '#include '? 33 | #include "priorityqueue.h" +++ |+#include 34 | /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:53:27: error: expected primary-expression before 'int' 53 | heap = std::make_unique( maxsize ); | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:3: error: 'p' was not declared in this scope 54 | p = std::make_unique( maxsize ); | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:12: error: 'make_unique' is not a member of 'std' 54 | p = std::make_unique( maxsize ); | ^~~~~~~~~~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:12: note: 'std::make_unique' is defined in header ''; did you forget to '#include '? /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:24: error: expected primary-expression before 'double' 54 | p = std::make_unique( maxsize ); | ^~~~~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:3: error: 'pos' was not declared in this scope 55 | pos = std::make_unique( maxId + 1 ); | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:14: error: 'make_unique' is not a member of 'std' 55 | pos = std::make_unique( maxId + 1 ); | ^~~~~~~~~~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:14: note: 'std::make_unique' is defined in header ''; did you forget to '#include '? /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:26: error: expected primary-expression before 'int' 55 | pos = std::make_unique( maxId + 1 ); | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'int pal::PriorityQueue::getBest()': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:84:28: error: 'heap' was not declared in this scope; did you mean 'upheap'? 84 | const int return_value = heap[0]; | ^~~~ | upheap /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:88:3: error: 'pos' was not declared in this scope 88 | pos[heap[0]] = -1; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:95:5: error: 'p' was not declared in this scope 95 | p[0] = p[size]; | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'bool pal::PriorityQueue::isIn(int) const': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:105:26: error: 'pos' was not declared in this scope 105 | return key <= maxId && pos[key] >= 0; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'int pal::PriorityQueue::getId(int) const': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:110:25: error: 'pos' was not declared in this scope 110 | return key <= maxId ? pos[key] : -1; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::insert(int, double)': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:118:3: error: 'heap' was not declared in this scope; did you mean 'upheap'? 118 | heap[size] = key; | ^~~~ | upheap /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:119:3: error: 'pos' was not declared in this scope 119 | pos[key] = size; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:120:9: error: 'class pal::PriorityQueue' has no member named 'p' 120 | this->p[size] = p; | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::remove(int)': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:135:17: error: 'pos' was not declared in this scope 135 | const int i = pos[key]; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:140:9: error: 'heap' was not declared in this scope; did you mean 'upheap'? 140 | pos[heap[size]] = i; | ^~~~ | upheap /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:144:5: error: 'p' was not declared in this scope 144 | p[i] = p[size]; | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::upheap(int)': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:177:7: error: 'pos' was not declared in this scope 177 | i = pos[key]; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:183:21: error: 'p' was not declared in this scope 183 | if ( greater( p[PARENT( i )], p[i] ) ) | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:187:13: error: 'heap' was not declared in this scope; did you mean 'upheap'? 187 | pos[heap[i]] = i2; | ^~~~ | upheap /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::downheap(int)': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:220:30: error: 'p' was not declared in this scope 220 | min_child = greater( p[RIGHT( id )], p[LEFT( id )] ) ? LEFT( id ) : RIGHT( id ); | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:228:19: error: 'p' was not declared in this scope 228 | if ( greater( p[id], p[min_child] ) ) | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:230:7: error: 'pos' was not declared in this scope 230 | pos[heap[id]] = min_child; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:230:11: error: 'heap' was not declared in this scope; did you mean 'upheap'? 230 | pos[heap[id]] = min_child; | ^~~~ | upheap /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::setPriority(int, double)': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:255:17: error: 'pos' was not declared in this scope 255 | const int i = pos[key]; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:263:3: error: 'p' was not declared in this scope 263 | p[i] = new_p; | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::decreaseKey(int)': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:276:17: error: 'pos' was not declared in this scope 276 | const int i = pos[key]; | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:281:3: error: 'p' was not declared in this scope 281 | p[i]--; | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::print()': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:297:72: error: 'heap' was not declared in this scope; did you mean 'upheap'? 297 | fprintf( stderr, "id: %7d -> key: %7d -> id: %7d p: %7f\n", i, heap[i], pos[heap[i]], p[i] ); | ^~~~ | upheap /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:297:81: error: 'pos' was not declared in this scope 297 | fprintf( stderr, "id: %7d -> key: %7d -> id: %7d p: %7f\n", i, heap[i], pos[heap[i]], p[i] ); | ^~~ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:297:95: error: 'p' was not declared in this scope 297 | fprintf( stderr, "id: %7d -> key: %7d -> id: %7d p: %7f\n", i, heap[i], pos[heap[i]], p[i] ); | ^ /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'int pal::PriorityQueue::getSizeByPos() const': /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:310:10: error: 'pos' was not declared in this scope 310 | if ( pos[i] >= 0 ) | ^~~ From even.rouault at spatialys.com Mon Nov 3 15:37:49 2025 From: even.rouault at spatialys.com (Even Rouault) Date: Tue, 4 Nov 2025 00:37:49 +0100 Subject: [QGIS-Developer] precompiled headers buggy, how to disable, compilation error In-Reply-To: References: Message-ID: <8ada5d6d-eb34-4d5e-8973-02b450b8d724@spatialys.com> adressed per https://github.com/qgis/QGIS/pull/63794 Le 03/11/2025 ? 23:54, Greg Troxel via QGIS-Developer a ?crit?: > This is a known problem with gcc, sort of addressed: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71934 > > After failing to disable pch with cmake, I edited the CMakeFiles where > target_precompiled_header existed and just removed it. Building again, > I don't get the warning, and things are mostly ok. One file failed to > build, and after fixing it (see below), I was able to get the build to > complete. > > My question is: > > Is there a way to add something to the cmake line to disable > precompiled headers? (It really seems like there should be.) > > > Greg > > > * src/core/pal/priorityqueue.cpp > > I got a complaint that was likely missing. I am guessing that > somehow precompiled headers include it somehow when building in that > mode -- although that seems buggy. > > I added a patch and it built. But obviously it's building for > ~everybody else. I wonder if others, if you remove the > "target_precompiled_headers" line, can build this file. > > > The patch: > > --- src/core/pal/priorityqueue.cpp.orig 2025-11-03 18:44:19.775172737 +0000 > +++ src/core/pal/priorityqueue.cpp > @@ -28,6 +28,7 @@ > */ > > #include > +#include > > #include "internalexception.h" > #include "priorityqueue.h" > > > The error output (without the patch): > > FAILED: [code=1] src/core/CMakeFiles/qgis_core.dir/pal/priorityqueue.cpp.o > /tmp/work/geography/qgis/work/.cwrapper/bin/c++ -DCMAKE_SOURCE_DIR=\"/tmp/work/geography/qgis/work/qgis-3.44.4\" -DPROTOBUF_USE_DLLS -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0x050800 -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH -DQT_POSITIONING_LIB -DQT_PRINTSUPPORT_LIB -DQT_SERIALPORT_LIB -DQT_SQL_LIB -DQT_SVG_LIB -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -DSIP_VERSION=0x060c00 -DTEST_DATA_DIR=\"/tmp/work/geography/qgis/work/qgis-3.44.4/tests/testdata\" -DWITH_COPC -DWITH_EPT -D_HAVE_PTHREAD_ -Dqgis_core_EXPORTS -I/tmp/work/geography/qgis/work/qgis-3.44.4/cmake-pkgsrc-build/src/core/qgis_core_autogen/include -I/tmp/work/geography/qgis/work/qgis-3.44.4/cmake-pkgsrc-build -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/poly2tri -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/ept -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/copc -I/tmp/work/geography/qgis/work/qg > is-3.44.4/src/core/providers/vpc -I/tmp/work/geography/qgis/work/qgis-3.44.4/cmake-pkgsrc-build/src/core -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/meshOptimizer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/3d -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/actions -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/annotations -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/auth -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/browser -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/callouts -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/classification -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/diagram -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/dxf -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/editform -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/effects -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/elevation -I/tmp/work/geography/qgis/work/qgis- > 3.44.4/src/core/expression -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/externalstorage -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/fieldformatter -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/geometry -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/geocoding -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/gps -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/labeling -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/labeling/rules -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/layertree -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/layout -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/locator -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/maprenderer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/mesh -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/metadata -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/network -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/numericformats -I/tmp/work/geography/q > gis/work/qgis-3.44.4/src/core/painting -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pdf -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/plot -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pointcloud -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pointcloud/expression -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/processing -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/processing/models -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/proj -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/project -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/arcgis -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/memory -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/gdal -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/ogr -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pr > oviders/meshmemory -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/providers/sensorthings -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/raster -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/renderer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/scalebar -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/settings -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/sensor -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/stac -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/symbology -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/textrenderer -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/tiledscene -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/validity -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/vector -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/vectortile -I/tmp/work/geography/qgis/work/qgis-3.44.4/src/core/web -I/tmp/work/geography/qgis/work/qgis-3.44.4/external -I/tmp/work/geography/qgis/work/qgis-3.44.4/exter > nal/delaunator-cpp -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/kdbush/include -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/nmea -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/rtree/include -I/tmp/work/geography/qgis/work/qgis-3.44.4/external/tinygltf -isystem /usr/pkg/qt5/include/Qca-qt5/QtCrypto -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtCore -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/./mkspecs/netbsd-g++ -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtGui -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtXml -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtWidgets -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtSvg -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtNetwork -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtSql -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtConcurrent -isystem /tmp/work/geography/qgis/work/.b > uildlink/qt5/include/QtPositioning -isystem /tmp/work/geography/qgis/work/.buildlink/include/geos -isystem /usr/pkg/qt5/include -isystem /usr/pkg/qt5/include/QtDBus -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtPrintSupport -isystem /usr/pkg/include -isystem /tmp/work/geography/qgis/work/.buildlink/qt5/include/QtSerialPort -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/python3.13 -Dz_off_t=long -I/usr/pkg/include/libxml2 -I/usr/pkg/include/minizip -I/usr/pkg/qt5/include -I/usr/pkg/include/glib-2.0 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/harfbuzz -I/usr/pkg/include/freetype2 -I/usr/X11R7/include -I/usr/X11R7/include/libdrm -I/usr/pkg/include/gstreamer-1.0 -I/usr/pkg/qwt-6.3.0/include -Wall -Wextra -Wno-long-long -Wformat-security -Wno-strict-aliasing -Wnon-virtual-dtor -Wno-redundant-move -Wno-misleading-indentation -Wno-deprecated-copy -std=gnu++17 -fPIC -fvisibility=hidden -fPIC -MD -MT src/core/CMakeFiles/qgis_ > core.dir/pal/priorityqueue.cpp.o -MF src/core/CMakeFiles/qgis_core.dir/pal/priorityqueue.cpp.o.d -o src/core/CMakeFiles/qgis_core.dir/pal/priorityqueue.cpp.o -c /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp > In file included from /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:33: > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:96:12: error: 'unique_ptr' in namespace 'std' does not name a template type > 96 | std::unique_ptr heap; > | ^~~~~~~~~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:37:1: note: 'std::unique_ptr' is defined in header ''; did you forget to '#include '? > 36 | #include > +++ |+#include > 37 | > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:97:12: error: 'unique_ptr' in namespace 'std' does not name a template type > 97 | std::unique_ptr p; > | ^~~~~~~~~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:97:7: note: 'std::unique_ptr' is defined in header ''; did you forget to '#include '? > 97 | std::unique_ptr p; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:98:12: error: 'unique_ptr' in namespace 'std' does not name a template type > 98 | std::unique_ptr pos; > | ^~~~~~~~~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.h:98:7: note: 'std::unique_ptr' is defined in header ''; did you forget to '#include '? > 98 | std::unique_ptr pos; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In constructor 'pal::PriorityQueue::PriorityQueue(int, int, bool)': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:53:3: error: 'heap' was not declared in this scope; did you mean 'upheap'? > 53 | heap = std::make_unique( maxsize ); > | ^~~~ > | upheap > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:53:15: error: 'make_unique' is not a member of 'std' > 53 | heap = std::make_unique( maxsize ); > | ^~~~~~~~~~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:34:1: note: 'std::make_unique' is defined in header ''; did you forget to '#include '? > 33 | #include "priorityqueue.h" > +++ |+#include > 34 | > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:53:27: error: expected primary-expression before 'int' > 53 | heap = std::make_unique( maxsize ); > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:3: error: 'p' was not declared in this scope > 54 | p = std::make_unique( maxsize ); > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:12: error: 'make_unique' is not a member of 'std' > 54 | p = std::make_unique( maxsize ); > | ^~~~~~~~~~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:12: note: 'std::make_unique' is defined in header ''; did you forget to '#include '? > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:54:24: error: expected primary-expression before 'double' > 54 | p = std::make_unique( maxsize ); > | ^~~~~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:3: error: 'pos' was not declared in this scope > 55 | pos = std::make_unique( maxId + 1 ); > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:14: error: 'make_unique' is not a member of 'std' > 55 | pos = std::make_unique( maxId + 1 ); > | ^~~~~~~~~~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:14: note: 'std::make_unique' is defined in header ''; did you forget to '#include '? > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:55:26: error: expected primary-expression before 'int' > 55 | pos = std::make_unique( maxId + 1 ); > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'int pal::PriorityQueue::getBest()': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:84:28: error: 'heap' was not declared in this scope; did you mean 'upheap'? > 84 | const int return_value = heap[0]; > | ^~~~ > | upheap > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:88:3: error: 'pos' was not declared in this scope > 88 | pos[heap[0]] = -1; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:95:5: error: 'p' was not declared in this scope > 95 | p[0] = p[size]; > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'bool pal::PriorityQueue::isIn(int) const': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:105:26: error: 'pos' was not declared in this scope > 105 | return key <= maxId && pos[key] >= 0; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'int pal::PriorityQueue::getId(int) const': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:110:25: error: 'pos' was not declared in this scope > 110 | return key <= maxId ? pos[key] : -1; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::insert(int, double)': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:118:3: error: 'heap' was not declared in this scope; did you mean 'upheap'? > 118 | heap[size] = key; > | ^~~~ > | upheap > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:119:3: error: 'pos' was not declared in this scope > 119 | pos[key] = size; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:120:9: error: 'class pal::PriorityQueue' has no member named 'p' > 120 | this->p[size] = p; > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::remove(int)': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:135:17: error: 'pos' was not declared in this scope > 135 | const int i = pos[key]; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:140:9: error: 'heap' was not declared in this scope; did you mean 'upheap'? > 140 | pos[heap[size]] = i; > | ^~~~ > | upheap > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:144:5: error: 'p' was not declared in this scope > 144 | p[i] = p[size]; > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::upheap(int)': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:177:7: error: 'pos' was not declared in this scope > 177 | i = pos[key]; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:183:21: error: 'p' was not declared in this scope > 183 | if ( greater( p[PARENT( i )], p[i] ) ) > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:187:13: error: 'heap' was not declared in this scope; did you mean 'upheap'? > 187 | pos[heap[i]] = i2; > | ^~~~ > | upheap > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::downheap(int)': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:220:30: error: 'p' was not declared in this scope > 220 | min_child = greater( p[RIGHT( id )], p[LEFT( id )] ) ? LEFT( id ) : RIGHT( id ); > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:228:19: error: 'p' was not declared in this scope > 228 | if ( greater( p[id], p[min_child] ) ) > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:230:7: error: 'pos' was not declared in this scope > 230 | pos[heap[id]] = min_child; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:230:11: error: 'heap' was not declared in this scope; did you mean 'upheap'? > 230 | pos[heap[id]] = min_child; > | ^~~~ > | upheap > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::setPriority(int, double)': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:255:17: error: 'pos' was not declared in this scope > 255 | const int i = pos[key]; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:263:3: error: 'p' was not declared in this scope > 263 | p[i] = new_p; > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::decreaseKey(int)': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:276:17: error: 'pos' was not declared in this scope > 276 | const int i = pos[key]; > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:281:3: error: 'p' was not declared in this scope > 281 | p[i]--; > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'void pal::PriorityQueue::print()': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:297:72: error: 'heap' was not declared in this scope; did you mean 'upheap'? > 297 | fprintf( stderr, "id: %7d -> key: %7d -> id: %7d p: %7f\n", i, heap[i], pos[heap[i]], p[i] ); > | ^~~~ > | upheap > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:297:81: error: 'pos' was not declared in this scope > 297 | fprintf( stderr, "id: %7d -> key: %7d -> id: %7d p: %7f\n", i, heap[i], pos[heap[i]], p[i] ); > | ^~~ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:297:95: error: 'p' was not declared in this scope > 297 | fprintf( stderr, "id: %7d -> key: %7d -> id: %7d p: %7f\n", i, heap[i], pos[heap[i]], p[i] ); > | ^ > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp: In member function 'int pal::PriorityQueue::getSizeByPos() const': > /tmp/work/geography/qgis/work/qgis-3.44.4/src/core/pal/priorityqueue.cpp:310:10: error: 'pos' was not declared in this scope > 310 | if ( pos[i] >= 0 ) > | ^~~ > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- http://www.spatialys.com My software is free, but my time generally not. From gdt at lexort.com Mon Nov 3 16:19:04 2025 From: gdt at lexort.com (Greg Troxel) Date: Mon, 03 Nov 2025 19:19:04 -0500 Subject: [QGIS-Developer] precompiled headers buggy, how to disable, compilation error In-Reply-To: <8ada5d6d-eb34-4d5e-8973-02b450b8d724@spatialys.com> (Even Rouault's message of "Tue, 4 Nov 2025 00:37:49 +0100") References: <8ada5d6d-eb34-4d5e-8973-02b450b8d724@spatialys.com> Message-ID: Even Rouault writes: > adressed per https://github.com/qgis/QGIS/pull/63794 Thanks -- that was fast! Addressed in more detail on github, but that works great for me and the resulting 3.44.4 package (built with gdal 3.12.0rc1 even) works fine. From nyall.dawson at gmail.com Mon Nov 3 17:34:19 2025 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Tue, 4 Nov 2025 11:34:19 +1000 Subject: [QGIS-Developer] Dirtying project within model classes or not In-Reply-To: <87a513oyjv.fsf@julienlaptop.home> References: <87a513oyjv.fsf@julienlaptop.home> Message-ID: On Tue, 4 Nov 2025 at 02:45, Julien Cabieces via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > > So, I'd like to know if we should: > - always dirty the project within model classes > - never dirty the project within model classes > - it depends... Thanks for raising this discussion Julien, I agree that a project-wide policy/guideline would be better than the ad-hoc approach we currently have. While I believe that conceptually dirtying a project IS an app level operation, my strongest counter-argument against dirtying from core classes is that not every class in core which "changes" a project HAS a way of notifying that project that it's been dirtied. For instance -- a layer's appearance can be changed via something like: layer->renderer()->symbol().setColor(...) There's NO way for symbols or renderers to notify the project (or even the layer) of these changes. A QgsSymbol doesn't (and shouldn't) keep a reference to its owner QgsFeatureRenderer, and the renderer doesn't keep a reference to its owner QgsVectorLayer. Neither QgsSymbol or QgsFeatureRenderer are QObjects (and they definitely should NOT be!!), so we can't eg emit signals from the symbol to notify of changes. The only way a change to one of these objects has to dirty a project would be a nasty QgsProject::instance()->setDirty() call, and (for good reason!) introduction of new occurrences of QgsProject::instance() is explicitly prohibited in core code. This leaves us in the situation where SOME calls to api methods in core classes dirties the project, but others have no possible way to do that. And this API inconsistency leads to a mess -- a caller would have no predictable way of knowing if any particular API call which effectively modifies a project will dirty the project or not, so they'll just need to manually dirty the project anyway to be certain. Or in short: if we dirty from core classes, we'll *always* have a need to *also* have dirty calls from gui/app. The alternative is to decide that dirtying belongs only at the app/gui level, and this makes things nice and predictable -- if a GUI / user operation changes the project, that gui/app code is responsible for dirtying the project. No ambiguity involved ? Nyall > > Regards, > Julien > > [0] https://github.com/qgis/QGIS/pull/63498#discussion_r2425462712 > [1] https://github.com/qgis/QGIS/blob/275c7d4466f5df99f7a7467d3331ce11a7394b8d/src/core/project/qgsproject.cpp#L490 > [2] https://github.com/qgis/QGIS/blob/275c7d4466f5df99f7a7467d3331ce11a7394b8d/src/core/project/qgsproject.cpp#L975 > > -- > > Julien Cabieces > Senior Developer at Oslandia > julien.cabieces at oslandia.com > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at qgis.org Mon Nov 3 23:56:46 2025 From: andreas at qgis.org (Andreas Neumann) Date: Tue, 4 Nov 2025 08:56:46 +0100 Subject: [QGIS-Developer] Status of 3.44 becoming LTR? In-Reply-To: References: Message-ID: Hi Greg, With the switch from QGIS 3.x to 4.x we are kind of breaking the rules around our otherwise strict schedules. This means that we skipped one release altogether and this also means that 3.44.x will be the last 3.x version and we decided it makes sense that the last 3.x version will eventually become LTR. I hope this makes sense. QGIS 4.x (currently 3.99.x) is still in early stages, but already usable. Plugins will have to update to work in QGIS 4.x. So I would wait a couple of 4.x releases to use it in production. Greetings, Andreas Andreas On Sun, 2 Nov 2025 at 16:44, Greg Troxel via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > I saw 3.40.12 and updated pkgsrc, and the .12 being pretty high made me > guess that there was a new LTR and I should look at it. I went to read > > https://qgis.org/resources/roadmap/ > > and after staring at it for a long time, my take is: > > - 3.44 is *going to be* LTR, but will not be blessed as such until > 3.44.8 in February > > - What is unusual is that LTR will be 3.44.8, not 3.46.4, because > there was no 3.46 in 2025-10, but we're still holding off until > February, because some blend of > + LTR promotion is always February > + LTR promotion of a future-LTR happens only when the next branch > .0 comes out. > > - 4.2 will become LTR in 2026-10, which is out of cycle, and probably > we'll then see 4.8 in 2027-10 with LTRs happening on October > instead of February. (That's an observation not a complaint.) > > If I'm confused a clue would be appreciated, and if 99.9% of the list > was already super clear sorry for the noise. > > Separately, given that pkgsrc is on the fence between "latest release is > fine" and "LTR is more stable and better", I should be planning to > switch from 3.40.x to 3.44.x, and any time between now and just after > the LTR-blessing of 3.44 on 2026-02-20 is a reasonable time to do that. > (I am building 3.44.4 from source and it's halfway through.) > > My impression is that 3.44 is entirely stable and that for normal users > (not trying to coordinate with other packaging systems in big > organizations, and not having the LTS "running old code on purpose is > good" outlook), there is no real reason to stay on 3.40. > > It is clear that I should try to package 4.0, or even 3.99, but as a > separate/experimental package, to surface and resolve qt6 issues. > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -- -- Andreas Neumann QGIS.ORG board member (treasurer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at qgis.org Mon Nov 3 23:57:23 2025 From: andreas at qgis.org (Andreas Neumann) Date: Tue, 4 Nov 2025 08:57:23 +0100 Subject: [QGIS-Developer] Status of 3.44 becoming LTR? In-Reply-To: References: Message-ID: See also https://blog.qgis.org/2025/10/07/update-on-qgis-4-0-release-schedule-and-ltr-plans/ where this was communicated. Andreas On Sun, 2 Nov 2025 at 16:44, Greg Troxel via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > I saw 3.40.12 and updated pkgsrc, and the .12 being pretty high made me > guess that there was a new LTR and I should look at it. I went to read > > https://qgis.org/resources/roadmap/ > > and after staring at it for a long time, my take is: > > - 3.44 is *going to be* LTR, but will not be blessed as such until > 3.44.8 in February > > - What is unusual is that LTR will be 3.44.8, not 3.46.4, because > there was no 3.46 in 2025-10, but we're still holding off until > February, because some blend of > + LTR promotion is always February > + LTR promotion of a future-LTR happens only when the next branch > .0 comes out. > > - 4.2 will become LTR in 2026-10, which is out of cycle, and probably > we'll then see 4.8 in 2027-10 with LTRs happening on October > instead of February. (That's an observation not a complaint.) > > If I'm confused a clue would be appreciated, and if 99.9% of the list > was already super clear sorry for the noise. > > Separately, given that pkgsrc is on the fence between "latest release is > fine" and "LTR is more stable and better", I should be planning to > switch from 3.40.x to 3.44.x, and any time between now and just after > the LTR-blessing of 3.44 on 2026-02-20 is a reasonable time to do that. > (I am building 3.44.4 from source and it's halfway through.) > > My impression is that 3.44 is entirely stable and that for normal users > (not trying to coordinate with other packaging systems in big > organizations, and not having the LTS "running old code on purpose is > good" outlook), there is no real reason to stay on 3.40. > > It is clear that I should try to package 4.0, or even 3.99, but as a > separate/experimental package, to surface and resolve qt6 issues. > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -- -- Andreas Neumann QGIS.ORG board member (treasurer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.cabieces at oslandia.com Tue Nov 4 00:22:02 2025 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Tue, 04 Nov 2025 09:22:02 +0100 Subject: [QGIS-Developer] Dirtying project within model classes or not In-Reply-To: (Nyall Dawson's message of "Tue, 4 Nov 2025 11:34:19 +1000") References: <87a513oyjv.fsf@julienlaptop.home> Message-ID: <87y0omnr6d.fsf@julienlaptop.home> > On Tue, 4 Nov 2025 at 02:45, Julien Cabieces via QGIS-Developer wrote: >> > >> So, I'd like to know if we should: >> - always dirty the project within model classes >> - never dirty the project within model classes >> - it depends... > > Thanks for raising this discussion Julien, I agree that a project-wide policy/guideline would be better than the ad-hoc approach we currently > have. While I believe that conceptually dirtying a project IS an app level operation, my strongest counter-argument against dirtying from core > classes is that not every class in core which "changes" a project HAS a way of notifying that project that it's been dirtied. > > For instance -- a layer's appearance can be changed via something like: > > layer->renderer()->symbol().setColor(...) > > There's NO way for symbols or renderers to notify the project (or even the layer) of these changes. A QgsSymbol doesn't (and shouldn't) keep a > reference to its owner QgsFeatureRenderer, and the renderer doesn't keep a reference to its owner QgsVectorLayer. Neither QgsSymbol or > QgsFeatureRenderer are QObjects (and they definitely should NOT be!!), so we can't eg emit signals from the symbol to notify of changes. The > only way a change to one of these objects has to dirty a project would be a nasty QgsProject::instance()->setDirty() call, and (for good reason!) > introduction of new occurrences of QgsProject::instance() is explicitly prohibited in core code. > Why not plain old callbacks instead of signals (I don't like that much signals, It's hard to debug, I think we use them too much). QgsSymbol could have some methods like this void addModifiedCallback( std::function callback ) { mCallbacks.append( callback ); } void dirty() { for( auto callback : mCallbacks ) callback(); } void setSize( double size ) { ... dirty(); } And QgsFeatureRenderer would report it to QgsVectorLayer, which would then report it to QgsProject > This leaves us in the situation where SOME calls to api methods in core classes dirties the project, but others have no possible way to do that. > And this API inconsistency leads to a mess -- a caller would have no predictable way of knowing if any particular API call which effectively > modifies a project will dirty the project or not, so they'll just need to manually dirty the project anyway to be certain. Or in short: if we dirty from > core classes, we'll *always* have a need to *also* have dirty calls from gui/app. > > The alternative is to decide that dirtying belongs only at the app/gui level, and this makes things nice and predictable -- if a GUI / user operation > changes the project, that gui/app code is responsible for dirtying the project. No ambiguity involved ? > Plugin developer could forget to dirty. And according to murphy law, if they could, they would! Doing it in core will prevent us from this > Nyall > >> >> Regards, >> Julien >> >> [0] https://github.com/qgis/QGIS/pull/63498#discussion_r2425462712 >> [1] https://github.com/qgis/QGIS/blob/275c7d4466f5df99f7a7467d3331ce11a7394b8d/src/core/project/qgsproject.cpp#L490 >> [2] https://github.com/qgis/QGIS/blob/275c7d4466f5df99f7a7467d3331ce11a7394b8d/src/core/project/qgsproject.cpp#L975 >> >> -- >> >> Julien Cabieces >> Senior Developer at Oslandia >> julien.cabieces at oslandia.com >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From dvdkon at konarici.cz Tue Nov 4 00:44:49 2025 From: dvdkon at konarici.cz (=?UTF-8?B?RGF2aWQgS2/FiGHFmcOtaw==?=) Date: Tue, 4 Nov 2025 09:44:49 +0100 Subject: [QGIS-Developer] Dirtying project within model classes or not In-Reply-To: <87y0omnr6d.fsf@julienlaptop.home> References: <87a513oyjv.fsf@julienlaptop.home> <87y0omnr6d.fsf@julienlaptop.home> Message-ID: <21d859f9-eee1-4772-a8b3-b06df4af64ba@konarici.cz> Hi all, On 11/4/25 09:22, Julien Cabieces via QGIS-Developer wrote: > Why not plain old callbacks instead of signals (I don't like that much > signals, It's hard to debug, I think we use them too much). QgsSymbol could have some > methods like this > > void addModifiedCallback( std::function callback ) > { > mCallbacks.append( callback ); > } > > void dirty() > { > for( auto callback : mCallbacks ) > callback(); > } > > void setSize( double size ) > { > ... > dirty(); > } > > And QgsFeatureRenderer would report it to QgsVectorLayer, which would > then report it to QgsProject I don't have an opinion on dirtying (due to lack of experience with it), but I do have an opinion on signals and callbacks: I agree that QGIS sometimes overuses signals, but I think callbacks are only a reasonable replacement where there will be exactly one callback, and only when that callback isn't stored in an object. Apart from the code duplication introduced by manually handling lists of callback functions (and slowly reimplementing signals ourselves), signals, when attached to objects, will automatically respond to the destruction of one of the endpoints. This means that properly-connected signals will never cause use-after-free issues, and that is reason enough to use them, in my opinion. David Ko?a??k From gdt at lexort.com Tue Nov 4 05:59:06 2025 From: gdt at lexort.com (Greg Troxel) Date: Tue, 04 Nov 2025 08:59:06 -0500 Subject: [QGIS-Developer] Status of 3.44 becoming LTR? In-Reply-To: (Andreas Neumann's message of "Tue, 4 Nov 2025 08:56:46 +0100") References: Message-ID: Andreas Neumann writes: > With the switch from QGIS 3.x to 4.x we are kind of breaking the rules > around our otherwise strict schedules. This means that we skipped one > release altogether and this also means that 3.44.x will be the last 3.x > version and we decided it makes sense that the last 3.x version will > eventually become LTR. I hope this makes sense. Yes, that makes sense and I understood the general plan. What I was not clear about was whether, today, 3.44 *was* the LTR or just *is going to be*. But from reading the roadmap, I convinced myself that today, 3.40 is LTR, and in late February, 3.44 will become LTR. Confusingly, 3.44 proclaims itself LTR in the splash screen, and it sort of is, kind of like crown prince. > QGIS 4.x (currently 3.99.x) is still in early stages, but already usable. > Plugins will have to update to work in QGIS 4.x. So I would wait a couple > of 4.x releases to use it in production. I guess that's really separate from the blessing of 4.2 as LTR. Then, once can presume that 4.2 is stable, but that doesn't mean plugins are ok. I guess every person/org has to assess what plugins they care about, test them, and if issues either fix them, pay someone else to fix, wait, or decide they don't care quite so much. From andreaerdna at libero.it Tue Nov 4 09:29:39 2025 From: andreaerdna at libero.it (Andrea Giudiceandrea) Date: Tue, 4 Nov 2025 18:29:39 +0100 Subject: [QGIS-Developer] Status of 3.44 becoming LTR? Message-ID: <6df71adb-e337-45d9-9aec-7a30b89abfc9@libero.it> Il 04/11/2025 14:59, Greg Troxel via QGIS-Developer ha scritto: > Confusingly, 3.44 > proclaims itself LTR in the splash screen, and it sort of is, kind of > like crown prince. Already reported [1] and fixed [2]. Regards. Andrea [1] https://github.com/qgis/QGIS/issues/63692 [2] https://github.com/qgis/QGIS/pull/63710 From jef at norbit.de Tue Nov 4 09:51:11 2025 From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer) Date: Tue, 4 Nov 2025 18:51:11 +0100 Subject: [QGIS-Developer] Status of 3.44 becoming LTR? In-Reply-To: References: Message-ID: <20251104175111.2ieagxyfxlnxghhd@norbit.de> Hi Greg, On Tue, 04. Nov 2025 at 08:59:06 -0500, Greg Troxel via QGIS-Developer wrote: > Yes, that makes sense and I understood the general plan. What I was not > clear about was whether, today, 3.44 *was* the LTR or just *is going to > be*. But from reading the roadmap, I convinced myself that today, 3.40 > is LTR, and in late February, 3.44 will become LTR. Confusingly, 3.44 > proclaims itself LTR in the splash screen, and it sort of is, kind of > like crown prince. Well, in my view the ltr is a branch that is longer maintained as others. So an ltr starts when it's branched off. We just build packages for the latest and long-term release and as that wouldn't make much sense while both are the same, we continue to build the previous ltr, while the new ltr is also the latest release. That way we still have two lines to build and the new ltr has some more time to replace the previous. That happens when the next version is released and takes its place as lastest release. That should also be the point were the splash is changed - which is usually with .4. That would have been - but should have happend with .8 on this branch. The splash change was meanwhile reverted. But I didn't bother to retag or do another point release just for this IMHO minor issue - the branch is a LTR branch. J?rgen -- J?rgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstra?e 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden https://www.norbit.de QGIS release manager (PSC) Germany IRC: jef on Libera|OFTC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nyall.dawson at gmail.com Tue Nov 4 11:11:35 2025 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Wed, 5 Nov 2025 05:11:35 +1000 Subject: [QGIS-Developer] Dirtying project within model classes or not In-Reply-To: <21d859f9-eee1-4772-a8b3-b06df4af64ba@konarici.cz> References: <87a513oyjv.fsf@julienlaptop.home> <87y0omnr6d.fsf@julienlaptop.home> <21d859f9-eee1-4772-a8b3-b06df4af64ba@konarici.cz> Message-ID: On Tue, 4 Nov 2025, 6:45?pm David Ko?a??k via QGIS-Developer, < qgis-developer at lists.osgeo.org> wrote: > > I don't have an opinion on dirtying (due to lack of experience with it), > but I do have an opinion on signals and callbacks: > > I agree that QGIS sometimes overuses signals, but I think callbacks are > only a reasonable replacement where there will be exactly one callback, > and only when that callback isn't stored in an object. > > Apart from the code duplication introduced by manually handling lists of > callback functions (and slowly reimplementing signals ourselves), > signals, when attached to objects, will automatically respond to the > destruction of one of the endpoints. This means that properly-connected > signals will never cause use-after-free issues, and that is reason > enough to use them, in my opinion. > +1. Effectively reimplementing qobject ourselves is not a good idea at all. Nyall > David Ko?a??k > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.cabieces at oslandia.com Wed Nov 5 05:33:41 2025 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Wed, 05 Nov 2025 14:33:41 +0100 Subject: [QGIS-Developer] Dirtying project within model classes or not In-Reply-To: <21d859f9-eee1-4772-a8b3-b06df4af64ba@konarici.cz> ("David =?utf-8?B?S2/FiGHFmcOtaw==?= via QGIS-Developer"'s message of "Tue, 4 Nov 2025 09:44:49 +0100") References: <87a513oyjv.fsf@julienlaptop.home> <87y0omnr6d.fsf@julienlaptop.home> <21d859f9-eee1-4772-a8b3-b06df4af64ba@konarici.cz> Message-ID: <87346sr4cq.fsf@julienlaptop.home> Hi David, Thank you for taking the time to answer this. > Hi all, > > On 11/4/25 09:22, Julien Cabieces via QGIS-Developer wrote: >> Why not plain old callbacks instead of signals (I don't like that much >> signals, It's hard to debug, I think we use them too much). QgsSymbol could have some >> methods like this >> void addModifiedCallback( std::function callback ) >> { >> mCallbacks.append( callback ); >> } >> void dirty() >> { >> for( auto callback : mCallbacks ) >> callback(); >> } >> void setSize( double size ) >> { >> ... >> dirty(); >> } >> And QgsFeatureRenderer would report it to QgsVectorLayer, which >> would >> then report it to QgsProject > > I don't have an opinion on dirtying (due to lack of experience with > it), but I do have an opinion on signals and callbacks: > > I agree that QGIS sometimes overuses signals, but I think callbacks > are only a reasonable replacement where there will be exactly one > callback, and only when that callback isn't stored in an object. > Why could we not have several callbacks ? And I'm not sure to really understand what you mean when you say "that callback isn't stored in an object". > Apart from the code duplication introduced by manually handling lists > of callback functions (and slowly reimplementing signals ourselves), > signals, when attached to objects, will automatically respond to the > destruction of one of the endpoints. This means that > properly-connected signals will never cause use-after-free issues, and > that is reason enough to use them, in my opinion. > signals/slots are way much than just simple callbacks as I described it in my previous email. They can use event loop and deal with inter thread communication for instance. So my proposal is IMHO far from reimplementing signals ourselves. Regarding use-after-free, indeed, the callee need to remove itself from the callback list on destruction, like all the ressources it manages. And code duplication could be avoided by putting the callback logic in some class to extend Regards, Julien > David Ko?a??k > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From julien.cabieces at oslandia.com Wed Nov 5 22:33:44 2025 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Thu, 06 Nov 2025 07:33:44 +0100 Subject: [QGIS-Developer] clang-tidy warning for narrowing to float In-Reply-To: ("David =?utf-8?B?S2/FiGHFmcOtaw==?= via QGIS-Developer"'s message of "Tue, 28 Oct 2025 09:55:20 +0100") References: <87y0ovqwfn.fsf@julienlaptop.home> Message-ID: <87v7jnoek7.fsf@julienlaptop.home> Hi, > Hi, > thanks for your input. We can, however, disable only some aspects of > the warning, and the only ones I'd like to disable are warnings on > floating point conversions. > > The PR you linked fixed a bug with an unwanted integer-to-integer > conversion. I'm convinced something like this couldn't happen with > float conversions, but feel free to send me counterexamples. > I don't have any. And we may never face such an issue like the one I pointed in int-to-float conversion. But there is data loss, so I'd rather be (too) cautious. But you're probable right and it's maybe overkill indeed. Regards, Julien > David Ko?a??k > > On 10/28/25 09:09, Julien Cabieces via QGIS-Developer wrote: >> Hi, >> I totally get your point, and I already faced such a situation where >> I >> have to introduce (too) many static_cast<>. On the other side, I already >> faced a situation where the use of this warning would have prevented a >> real issue [0]. >> So, I'm not really in favor of your proposal because it would >> disable >> the warning for the whole codebase, on some situation where it could be relevant. Could we not instead: >> - introduce float getters/setters to have the conversion at only one place >> - just have some converted variable "const float fvar = >> static_cast( var )". I don't think it makes the code so difficult >> to read. >> Regards, >> Julien >> [0] https://github.com/qgis/QGIS/pull/50016 >> >>> Hi all, >>> I'd like to propose a change to QGIS's clang-tidy settings. Currently, >>> we have bugprone-narrowing-conversions [0] turned on by wildcard, >>> which by default warns on converting between integer types, between >>> floating point types, and from integers to floating points, if the >>> full range of the source type won't fit into the destination type >>> without loss of precision. >>> >>> I fully agree that conversions between different integer types should >>> be conscious decisions, since they can lead to security issues [1]. I >>> find the floating point warnings to have dubious usefulness, though. >>> >>> In QGIS' 3D code, we often need to use integer values (e.g. screen >>> size) in floating point calculations, with practically no chance that >>> the integer value won't be representable as a float, and zero risk >>> even if it is - creating a security issue would require a very >>> creative abuse of floats. Fixing the warning leads to a visual spam of >>> static_cast()s everywhere, obscuring any actual bugs. >>> >>> Converting doubles to floats can actually cause issues, but it's also >>> inevitable in many places, seeing as Qt3D uses floats, but we need to >>> use doubles ourselves for precision reasons. Given this, I also think >>> the warning isn't very useful here. >>> >>> I propose turning off WarnOnIntegerToFloatingPointNarrowingConversion >>> and possibly WarnOnFloatingPointNarrowingConversion, based on your >>> feedback. >>> >>> David Ko?a??k >>> >>> [1]: >>> https://clang.llvm.org/extra/clang-tidy/checks/bugprone/narrowing-conversions.html >>> [0]: e.g. char *copy_string(char *str, uint64_t str_size) { >>> uint32_t size_plus_null = str_size + 1; >>> char *copy = malloc(size_plus_null); >>> memcpy(copy, str, str_size); >>> copy[str_size] = '\0'; >>> return copy; >>> } >>> _______________________________________________ >>> QGIS-Developer mailing list >>> QGIS-Developer at lists.osgeo.org >>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From rdmailings at duif.net Thu Nov 6 00:07:53 2025 From: rdmailings at duif.net (Richard Duivenvoorde) Date: Thu, 6 Nov 2025 09:07:53 +0100 Subject: [QGIS-Developer] 3.44 keeps asking for CRS Transformation every time??? Message-ID: Hi, At a client they have installed QGIS 3.44 on Windows. There is a project with some layers. Every time they open that project the "Select Transformation for ..." keeps popping up. And it keeps popping up every time you open the project, even if you check the 'Make default' checkbox and save the project again and again. I now have it here on my Debian laptop too, it's not very clear which kind of layers are affected, but at least the WFS layers are. I have attached a QGIS project with only one WFS layer. Can others reproduce this in QGIS 3.44 (and master...)? I'll create a ticket as anybody can reproduce this... Regards, Richard Duivenvoorde -------------- next part -------------- A non-text attachment was scrubbed... Name: testwfs.qgs Type: application/x-qgis Size: 56832 bytes Desc: not available URL: From pjduplooy.gis at gmail.com Thu Nov 6 00:26:00 2025 From: pjduplooy.gis at gmail.com (Gandalf the Gray) Date: Thu, 6 Nov 2025 10:26:00 +0200 Subject: [QGIS-Developer] 3.44 keeps asking for CRS Transformation every time??? In-Reply-To: References: Message-ID: Richard. Happens on my Windows Machine too.(3.44). Pieter On Thu, Nov 6, 2025 at 10:14?AM Richard Duivenvoorde via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Hi, > > At a client they have installed QGIS 3.44 on Windows. There is a project > with some layers. Every time they open that project the "Select > Transformation for ..." keeps popping up. > And it keeps popping up every time you open the project, even if you check > the 'Make default' checkbox and save the project again and again. > > I now have it here on my Debian laptop too, it's not very clear which kind > of layers are affected, but at least the WFS layers are. > > I have attached a QGIS project with only one WFS layer. > Can others reproduce this in QGIS 3.44 (and master...)? > I'll create a ticket as anybody can reproduce this... > > Regards, > > Richard Duivenvoorde > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochenschwarze70 at posteo.de Thu Nov 6 01:59:29 2025 From: jochenschwarze70 at posteo.de (Jochen Schwarze) Date: Thu, 06 Nov 2025 09:59:29 +0000 Subject: [QGIS-Developer] 3.44 keeps asking for CRS Transformation every time??? In-Reply-To: References: Message-ID: Hi, we had a comparable issue with a prior LTR, it was related to an outdated proj.db, cp. Regards, Jochen Schwarze Am 6. November 2025 09:07:53 MEZ schrieb Richard Duivenvoorde via QGIS-Developer : >Hi, > >At a client they have installed QGIS 3.44 on Windows. There is a project with some layers. Every time they open that project the "Select Transformation for ..." keeps popping up. >And it keeps popping up every time you open the project, even if you check the 'Make default' checkbox and save the project again and again. > >I now have it here on my Debian laptop too, it's not very clear which kind of layers are affected, but at least the WFS layers are. > >I have attached a QGIS project with only one WFS layer. >Can others reproduce this in QGIS 3.44 (and master...)? >I'll create a ticket as anybody can reproduce this... > >Regards, > >Richard Duivenvoorde -------------- next part -------------- An HTML attachment was scrubbed... URL: From rdmailings at duif.net Thu Nov 6 02:24:34 2025 From: rdmailings at duif.net (Richard Duivenvoorde) Date: Thu, 6 Nov 2025 11:24:34 +0100 Subject: [QGIS-Developer] 3.44 keeps asking for CRS Transformation every time??? In-Reply-To: References: Message-ID: Hi Jochen, I've seen this on too many places now. Last week I created a Virtual Windows11 machine, installed 3.40.12 on it, and this project still keeps asking for transformation... BUT now I see that after the CRS Transformation questions, the project crs (right corner) shows No CRS.... I really do not know how I ended up here. But I've seen this a couple of times now around me too. So apparently a project can at a certain moment end up as a 'No CRS' project, and THEN this popup popping starts ? If I now set the project crs again, the popups disappear. But then I think the question is how people (it's not only my project files) end up here? And should QGIS not put a crs on a project after choosing a CRS Transformation for the layer? Or warn the user? Or just do not ask for the transformation if there is NO project crs? Regards, Richard Duivenvoorde On 11/6/25 10:59, Jochen Schwarze wrote: > Hi, we had a comparable issue with a prior LTR, it was related to an outdated proj.db, cp. > > > > Regards, Jochen Schwarze > > > Am 6. November 2025 09:07:53 MEZ schrieb Richard Duivenvoorde via QGIS-Developer : > > Hi, > > At a client they have installed QGIS 3.44 on Windows. There is a project with some layers. Every time they open that project the "Select Transformation for ..." keeps popping up. > And it keeps popping up every time you open the project, even if you check the 'Make default' checkbox and save the project again and again. > > I now have it here on my Debian laptop too, it's not very clear which kind of layers are affected, but at least the WFS layers are. > > I have attached a QGIS project with only one WFS layer. > Can others reproduce this in QGIS 3.44 (and master...)? > I'll create a ticket as anybody can reproduce this... > > Regards, > > Richard Duivenvoorde > From tom at sparkgeo.com Thu Nov 6 17:45:12 2025 From: tom at sparkgeo.com (Tom Christian) Date: Thu, 6 Nov 2025 17:45:12 -0800 Subject: [QGIS-Developer] Development environment setup Message-ID: <8132C8FA-A075-4B36-8C98-1ADD8E360C03@sparkgeo.com> Hi All, I am interested in learning more about how QGIS developers configure their development environments, and I would like to get some feedback on an alternate approach. I recently contributed my first changes to QGIS and I found the development environment quite challenging. While the QGIS Developers Guide contains lots of information I found most of it to be high-level, e.g. how to work with Git, and there was limited information on gathering required dependencies and setting build configurations. Given the number of dependencies, the risk of conflicts with existing packages, and my strong preference to avoid VMs, I thought a containerised build environment was ideal. My work requires frequently switching between projects and environments. I generally cannot let any one project's dependencies pollute the system outside of a Conda environment, a container, or a VM. I found the CI Docker configuration and thought I could use this to build and test QGIS. These Dockerfiles should guarantee all required dependencies AND this is the environment that passes or fails CI checks on my changes. Building QGIS using the CI Docker configuration was OK, but CI is not setup for running the build product in a container - meaning changes cannot quickly be manually / visually tested in this way. The project would have to be compiled (with the benefit of mounted ccache) and installed every time the container was started before the application could run. The long Docker commands are not currently scripted outside of GitHub Actions Workflows, and build configurations are provided via matrices, so replicating these processes locally is non-trivial. I created this repo to better automate container-based development and testing of QGIS. It contains build / run / test scripts, .env configurations, and Docker Compose overrides to work with the QGIS CI Docker configuration with as few changes as possible. It currently requires a single small commit in the active QGIS branch to support this approach, which I removed before creating PRs for the main QGIS repo. With this approach, building and running a containerised QGIS development build is (in theory) as simple as scripts/run.sh. Tests can be executed with scripts/test.sh. I have some questions: 1) are you installing QGIS build dependencies on "bare metal", or perhaps using a VM? 2) is there a simpler approach than this for containerised builds, runs, and tests? 2a) if not, is there any interest in pursuing this or a similar approach to simplify containerised development environments? Ultimately I suspect the QGIS project would benefit from lower barriers to entry and the ability to better isolate build dependencies. -------------- next part -------------- An HTML attachment was scrubbed... URL: