Hi > On 19. Jan 2022, at 06:22, Konstantin Shegunov <kshegu...@gmail.com> wrote: > > On that note the CMake people have an open ticket to provide decorating at > link time which should cover such a possible use case in the future[1]. > Whether this gets in, remains to be seen, but from a glance does seem > somewhat advanced in the MR review. > [1]: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6769
As far as I know, the referenced merge request only implements an abstraction for decorations, but does not implement the specific decoration of making sure a library is not discarded. See https://gitlab.kitware.com/cmake/cmake/-/issues/22812#note_1074118 https://bugreports.qt.io/browse/QTBUG-97816 https://bugreports.qt.io/browse/QTBUG-80863?focusedCommentId=566874&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-566874 Multiple people have investigated this and so far we've not found a good enough solution. > On that note, is there a specific reason I'm missing that qt_add_qml_module > doesn't do this, but instead requires the consuming target to ensure that a > symbol is accessed? Perhaps, provided there are no problems that I'd missed, > this could be an "improvement"; in the sense that it's not going to be done > manually anymore, and can be neatly integrated into the CMake scripts. There are WIP changes that try to do that. See https://codereview.qt-project.org/c/qt/qtdeclarative/+/367149 The problem is, you need CMake 3.21 to implement it robustly (propagate the object library that references the symbol, all the way to the executable or custom shared library). With lower versions, the object file / object library might get silently discarded. For shared Qt builds, we require 3.16 as a minimum, so it's still not a solution can we can claim to work in all cases. _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
