-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmake: Stop calling QT5_WRAP_CPP() when building quazip and libqpsd. #187
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cmake/Utils.cmake already sets CMAKE_AUTOMOC to on. Calling QT5_WRAP_CPP() used to be just redundant, as QUAZIP_MOC_SRC and LIBQPSD_MOC_SRC were never actually added as source dependencies in MacBuildTarget.cmake and UnixBuildTarget.cmake. In other words, CMake's own automoc infrastructure was actually being used and the moc invocations from QT5_WRAP_CPP() were not being made at all. Starting with Qt 5.9.4, calling QT5_WRAP_CPP() disables the AUTOMOC property on the macro's input files, which means neither CMake's automoc infrastructure not QT5_WRAP_CPP()'s code were being used and we ended up with several 'undefined reference to vtable' errors when linking.
uqs
pushed a commit
to freebsd/freebsd-ports
that referenced
this pull request
Jan 29, 2018
cmake/Utils.cmake already sets CMAKE_AUTOMOC to on. Calling QT5_WRAP_CPP() used to be just redundant, as QUAZIP_MOC_SRC and LIBQPSD_MOC_SRC were never actually added as source dependencies in MacBuildTarget.cmake and UnixBuildTarget.cmake. In other words, CMake's own automoc infrastructure was actually being used and the moc invocations from QT5_WRAP_CPP() were not being made at all. Starting with Qt 5.9.4, calling QT5_WRAP_CPP() disables the AUTOMOC property on the macro's input files, which means neither CMake's automoc infrastructure not QT5_WRAP_CPP()'s code were being used and we ended up with several 'undefined reference to vtable' errors when linking. Sent upstream: nomacs/nomacs#187 PR: 225436 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@460286 35697150-7ecd-e111-bb59-0022644237b5
uqs
pushed a commit
to freebsd/freebsd-ports
that referenced
this pull request
Jan 29, 2018
cmake/Utils.cmake already sets CMAKE_AUTOMOC to on. Calling QT5_WRAP_CPP() used to be just redundant, as QUAZIP_MOC_SRC and LIBQPSD_MOC_SRC were never actually added as source dependencies in MacBuildTarget.cmake and UnixBuildTarget.cmake. In other words, CMake's own automoc infrastructure was actually being used and the moc invocations from QT5_WRAP_CPP() were not being made at all. Starting with Qt 5.9.4, calling QT5_WRAP_CPP() disables the AUTOMOC property on the macro's input files, which means neither CMake's automoc infrastructure not QT5_WRAP_CPP()'s code were being used and we ended up with several 'undefined reference to vtable' errors when linking. Sent upstream: nomacs/nomacs#187 PR: 225436
Jehops
pushed a commit
to Jehops/freebsd-ports-legacy
that referenced
this pull request
Jan 29, 2018
cmake/Utils.cmake already sets CMAKE_AUTOMOC to on. Calling QT5_WRAP_CPP() used to be just redundant, as QUAZIP_MOC_SRC and LIBQPSD_MOC_SRC were never actually added as source dependencies in MacBuildTarget.cmake and UnixBuildTarget.cmake. In other words, CMake's own automoc infrastructure was actually being used and the moc invocations from QT5_WRAP_CPP() were not being made at all. Starting with Qt 5.9.4, calling QT5_WRAP_CPP() disables the AUTOMOC property on the macro's input files, which means neither CMake's automoc infrastructure not QT5_WRAP_CPP()'s code were being used and we ended up with several 'undefined reference to vtable' errors when linking. Sent upstream: nomacs/nomacs#187 PR: 225436 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@460286 35697150-7ecd-e111-bb59-0022644237b5
swills
pushed a commit
to swills/freebsd-ports
that referenced
this pull request
Jan 29, 2018
cmake/Utils.cmake already sets CMAKE_AUTOMOC to on. Calling QT5_WRAP_CPP() used to be just redundant, as QUAZIP_MOC_SRC and LIBQPSD_MOC_SRC were never actually added as source dependencies in MacBuildTarget.cmake and UnixBuildTarget.cmake. In other words, CMake's own automoc infrastructure was actually being used and the moc invocations from QT5_WRAP_CPP() were not being made at all. Starting with Qt 5.9.4, calling QT5_WRAP_CPP() disables the AUTOMOC property on the macro's input files, which means neither CMake's automoc infrastructure not QT5_WRAP_CPP()'s code were being used and we ended up with several 'undefined reference to vtable' errors when linking. Sent upstream: nomacs/nomacs#187 PR: 225436 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@460286 35697150-7ecd-e111-bb59-0022644237b5
bob-beck
pushed a commit
to openbsd/ports
that referenced
this pull request
Jan 30, 2018
Stop calling QT5_WRAP_CPP() when building libqpsd. -- nomacs/nomacs#187 Spotted by naddy@ sthen@ landry@ Final hint by naddy@ Thanks!
thx! |
svmhdvn
pushed a commit
to svmhdvn/freebsd-ports
that referenced
this pull request
Jan 10, 2024
cmake/Utils.cmake already sets CMAKE_AUTOMOC to on. Calling QT5_WRAP_CPP() used to be just redundant, as QUAZIP_MOC_SRC and LIBQPSD_MOC_SRC were never actually added as source dependencies in MacBuildTarget.cmake and UnixBuildTarget.cmake. In other words, CMake's own automoc infrastructure was actually being used and the moc invocations from QT5_WRAP_CPP() were not being made at all. Starting with Qt 5.9.4, calling QT5_WRAP_CPP() disables the AUTOMOC property on the macro's input files, which means neither CMake's automoc infrastructure not QT5_WRAP_CPP()'s code were being used and we ended up with several 'undefined reference to vtable' errors when linking. Sent upstream: nomacs/nomacs#187 PR: 225436
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
cmake/Utils.cmake
already setsCMAKE_AUTOMOC
to on.Calling
QT5_WRAP_CPP()
used to be just redundant, asQUAZIP_MOC_SRC
andLIBQPSD_MOC_SRC
were never actually added as source dependencies inMacBuildTarget.cmake
andUnixBuildTarget.cmake
. In other words, CMake's ownautomoc infrastructure was actually being used and the moc invocations from
QT5_WRAP_CPP()
were not being made at all.Starting with Qt 5.9.4, calling
QT5_WRAP_CPP()
disables theAUTOMOC
propertyon the macro's input files, which means neither CMake's automoc
infrastructure not
QT5_WRAP_CPP()
's code were being used and we ended upwith several 'undefined reference to vtable' errors when linking.