On 11/13/16 19:50, Rafael Sadowski wrote:
> On Sat Nov 12, 2016 at 11:17:18PM +0100, Jeremie Courreges-Anglas wrote:
>> Nigel Taylor <njtaylor0...@btinternet.com> writes:
>>
>>> On 10/22/16 16:42, Rafael Sadowski wrote:
>>>> On Tue Sep 20, 2016 at 01:33:34AM +0100, Stuart Henderson wrote:
>>>>> These plist changes for every update are getting silly, I think I'd
>>>>> rather disable doxygen in those ports..
>>>>>
>>>>
>>>> Other opinions or agreements?
>>>>
>>>
>>> I don't build qt5/kde4/kde5 for amd64.
>>>
>>> From what I see, the -gui and hence inclusion qt5 has no point it
>>> doesn't appear to be used in other ports. If no one actually uses the
>>> -gui spending a lot of time building qt5 / and -gui for nothing.
>>>
>>> Because of the size of qt5 this should be split into two ports, rather
>>> than using the PSEUDO_FLAVOR otherwise all the ports listed will be
>>> waiting on the qt5 build to complete when using dpb.
>>>
>>> qt5 itself needs splitting using the separate source files provided,
>>> rather then the combined file with everything needed or not.
>>>
>>> As is I will be just removing -gui / PSEUDO_FLAVOR from the port for myself.
>>
>> Instead of people having to maintain local patches, wouldn't it be
>> better to remove qt5 from this build path? That can surely be done
>> without killing the -gui package.
>>
>>> The same way I have removed kde4 from editors/libreoffice, qt, qt4, qt5
>>> from print/poppler.
>>
>>> The PLIST issue is gnerating html documentation with changed scripts,
>>> images, with the same names
>>>
>>>
>>> also as far as I can see there is an option to force the use of Qt4 if
>>> Qt5 is present.
>>>
>>> From doxygen install document it says...
>>>
>>> <li>Qt Software's GUI toolkit
>>> <a href="http://qt-project.org/";>Qt</A>
>>> \addindex Qt
>>> version 4.3 or higher (but currently, Qt 5.x is not yet supported).
>>> This is needed to build the GUI front-end doxywizard.
>>>
>>> I searched the changelog not a single mention of a switch to Qt5
>>>
>>> This looks like we are switching to Qt5 because it being built / test on
>>> a machine with Qt5 installed else the switch to Qt5 hasn't been documented.
>
> No, the worst think about doxygen is the documentation ;). That's sad
> but everting is clear and well readable in the CMake environment. Qt5 is
> default on and Qt4 only available with the option "force_qt4".
>
>>>
>>> So why is this even using Qt5.
>>
>> Upstream made the choice of introducing Qt5 compatibility in this
>> release, and to use Qt5 by default. doxywizard runs fine here.
>> To me it looks like a case of slightly outdated information on the
>> website.
>>
>> Note that this diff has been floating on the mailing-list since some
>> time already, you could have voiced objections earlier. ;)
>>
>
> Diff below based on jca@ idea. "no_gui bootstrap" is set as default.
>
> Kind regards,
>
> Rafael Sadowski
>
> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/devel/doxygen/Makefile,v
> retrieving revision 1.37
> diff -u -p -u -p -r1.37 Makefile
> --- Makefile 12 Nov 2016 20:59:18 -0000 1.37
> +++ Makefile 13 Nov 2016 19:35:50 -0000
> @@ -29,6 +29,7 @@ MASTER_SITES= http://ftp.stack.nl/pub/us
>
> MULTI_PACKAGES= -main -gui
> PSEUDO_FLAVORS= no_gui bootstrap
> +FLAVOR?= no_gui bootstrap
>
> COMMON_WANTLIB= c m pthread estdc++
> WANTLIB-main= ${COMMON_WANTLIB} iconv z xapian
>
>
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.
It also exposes it to dpb failures that can junk the library / gcc4, and
build with base stdc++ instead. Requires a junk to occur between
patching and configure is difficult to reproduce with dpb.
The runtime may also fail if something else hasn't installed the
library. Then could then cause dpb bulk to fail building the dependent
packages as estdc++ is not present.
None of this is proved. Have to pkg_delete nearly all the packages to
see the problems.
$ env FLAVOR="no_gui bootstrap" make show=LIB_DEPENDS
$ env FLAVOR=no_gui make show=LIB_DEPENDS
$ env FLAVOR= make show=LIB_DEPENDS
x11/qt5 STEM->=4.9,<4.10:lang/gcc/4.9,-libs
$ env SUBPACKAGE=-main FLAVOR= make show=LIB_DEPENDS
x11/qt5 STEM->=4.9,<4.10:lang/gcc/4.9,-libs
$ env SUBPACKAGE=-main make show=LIB_DEPENDS
x11/qt5 STEM->=4.9,<4.10:lang/gcc/4.9,-libs
$ env SUBPACKAGE=-gui make show=LIB_DEPENDS
x11/qt5 STEM->=4.9,<4.10:lang/gcc/4.9,-libs
There is no combination with just the library and no qt5... Only both or
neither. The library always needs to be present if estdc++ is in both
WANTLIB's you can't rely on a MODULE in a conditional.
