most module project files define two logical modules: a public one and
the corresponding private one. these are really separate modules as far
as qmake is concerned (even though the private one contains just
headers), and consequently have separate dependencies - QT and
QT_FOR_PRIVATE.
as public modules cannot depend on private ones, all private
dependencies would have to go to QT_FOR_PRIVATE, and a dependency on the
respective public module would have to be added to QT. this would be a
bit tedious, so we have a convenience feature which allows putting
private dependencies into QT, but automatically "downgrades" them to
their public counterpart when creating the public module's .pri file.
however, we failed to put verbatim versions of these private
dependencies into the private modules, which meant that these
dependencies were not pulled in transitively by the private modules'
users.
note that this entirely unrelated to QT_PRIVATE - this one defines the
private (non-propagated) dependencies of the module's implementation,
i.e., the libraries (and headers) that are not part of the link
interface. there is no QT_PRIVATE_FOR_PRIVATE, because there is
obviously no point in assigning the dependencies to a particular
logical submodule when neither one inherits them as far as the qt
module system is concerned.
Change-Id: Ib056b47dde3341ef9a52ffff13efaf8ef8e6817b
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
b8bee40726