Skip to content
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
merged 1 commit into from
Feb 8, 2018

Conversation

rakuco
Copy link
Contributor

@rakuco rakuco commented 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.

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!
@diemmarkus
Copy link
Member

thx!

@diemmarkus diemmarkus merged commit 0dd188d into nomacs:master Feb 8, 2018
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants