Stuart Henderson <s...@spacehopper.org> writes:
> 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.
I'd prefer this option.
> 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.
Right. *sigh*
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
