Hi, just for clarification: If we factor out shared resources into a library, then that wouldn't be one big QtExamplesShared module, but rather one library per module (unless something actually needs to be shared across multiple modules, e.g. icons). Anything else would require moving examples to a leaf module like qtdoc to handle the dependencies in the CI, which isn't something we want here.
I would argue that putting actually shared resources into such libraries is a good idea, regardless of whether we need it for junctions or not – after all, it promotes a sane way of sharing resources in our examples. Whereas I doubt that we want to promote the relative path inclusion for the projects our users start. Regards, Fabian ________________________________________ Von: Development <development-boun...@qt-project.org> im Auftrag von Kai Köhne via Development <development@qt-project.org> Gesendet: Donnerstag, 7. März 2024 13:02 An: qt-development Betreff: [Development] Qt Examples need to be self-contained Hi, We have quite a few Qt examples and tutorials that share assets (images, sources, ...) via relative paths in the file system. That is, there's often a 'shared' directory that multiple examples use by relative paths (see e.g. https://code.qt.io/cgit/qt/qtdeclarative.git/tree/examples/quick/shared). My suggestion is to officially ban this, and * either duplicate the relevant sources and assets in the respective example directories, or * create a static 'QtModuleExamplesPrivate' library that is built as part of Qt, and can be referenced by these examples - something we already discussed & implemented before e.g. for sharing icons. Proposed change in QUIP-13 is at https://codereview.qt-project.org/c/meta/quips/+/546086 Why this change? Qt Creator 13 will get a feature to shorten build paths by creating Junction Points (basically symbolic links) on Windows. This is to prevent file paths and build command lines from becoming too long, an issue that has been a never-ending source of frustration especially for new users on Windows The issue of long file paths breaking builds is something that has been impeding users since forever. It became even more urgent though in the last years due to the deep nested structures that Qt Quick and the relevant tooling endorses (see e.g. https://bugreports.qt.io/browse/QTBUG-117413). Its root cause can arguably only be fixed on Microsoft's side - but chances for this are IMO slim ... So, shortening build paths as part of Qt Creator seems our best 'general' cure for now. As the build path will however not be the source path, navigating across the file system with things like #include "../../../../shared/shared.h" will break. If we agree on this, we would prepare matching bug reports for affected examples. Regards Kai PS: To be clear, this is not something we still have to fix for Qt 6.7.0. For now, the use of Junction points in Qt Creator is still opt-in. When we fix examples, we should still backport them to older Qt versions though. -- Kai Köhne, Director R&D | The Qt Company The Qt Company GmbH, Erich-Thilo-Str. 10, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
