On 2016/11/13 21:26, Nigel Taylor wrote:
> >
> I will not be able to test building that for sometime as in middle of
> dpb run, I would say that it will fail. Not proved, but the estdc++ in
> the wantlib requires the library to be installed, that requires a
> dependency set by x11/qt5.port.mk,
>
> MODQT5_USE_GCC4_MODULE ?= Yes
> .if ${MODQT5_USE_GCC4_MODULE} == "Yes"
> MODULES += gcc4
> MODGCC4_LANGS += c++
> MODGCC4_ARCHS ?= *
> .endif
>
> which means either qt5 and gcc4 plus the library is installed or the
> library isn't installed then relies on the chance dpb has installed gcc4
> the library in building something else. Before stdc++ from base was used
> for earlier version with qt4.
>
> This would require a LDEP change, and possibly a revision bump also, or
> the inclusion of the gcc4 module and revision bump.
Yep, valid concern.
As well as the ones you've suggested there's another option too.
Any of these should work:
1. add the gcc4 module to doxygen so that the no_gui pseudo-flavour is
also built with ports gcc. simple, but downside: pushes anything using
doxygen later in dpb.
2. turn the no_gui pseudo-flavour back into a real flavour with a
PFRAG for the gui bits. @pkgpath devel/doxygen,-gui would go in the
pfrag.
3. split the gui off to a different port. keep the same pkgname stem,
so it just needs an @pkgpath in PLIST for updates to work.
Whichever is chosen, the current situation is wrong because no_gui is
only a pseudo-flavour so it is only meant to select which subpackages
are built and not change anything else; however at present it is also
changing which compiler is used.
