As you say it's not a FLAVOR what's this in the Makefile for
-CONFIGURE_STYLE= gnu
+MULTI_PACKAGES = -main -qt -py2 -py3
+PSEUDO_FLAVORS = no_qt no_py2 no_py3
+FLAVOR ?=
As subpackage is even worse so even the simplest ports using gpgme needs
Qt5 built to build.
On 11/03/17 15:39, Jeremie Courreges-Anglas wrote:
> On Thu, Nov 02 2017, Nigel Taylor <njtaylor0...@btinternet.com> wrote:
>> Should you promote gpgme-qt to be the default flavor over others
>
> It's a subpackage, not a flavor.
>
>> FLAVOR ?=
>>
>> should default to no_qt no_python2 no_python3, that is the default as
>> before. Building with qt should be an extra, in fact use of this sort of
>> complex PSEUDO_FLAVOR causes problems especially with something as large
>> as qt5, which means dpb can't be used for build a subset of packages.
>>
>> I dpb tries to build security/gpgme,no_qt,no_py2,no_py3,-main as
>> effectively used by all current ports using gpgme which would have to be
>> changed in the ports tree.
>>
>> The existing dpb xxx/yyy or list that built a subset of packages, this
>> change on seeing reference to security/gpgme will build not only the
>> packages as before, but all the packages for the included modules, that
>> is python2 and sub packages, python3 and sub packages, and the whole of qt5.
>>
>> This is enforcing qt5 on those who don't want and don't need qt5.
>>
>> python2 / python3 I can live with. qt5 I can live without.
>>
>> For those wanting a small light weight system, qt5 - everywhere -
>> everything just isn't what they want.
>
> This is not about qt5 everywhere, this about qt5 on the build machine;
> remember that the ports tree is optimized for bulk builds.
>
> I'm *much more* concerned about introducing a hard dep on a C++11
> compiler (and Qt5?) on such an important library.
>
>> Just why should if we want a small light weight system should we need to
>> go around adding in no_qt,no_py2,no_py3,-main to everything? Maybe here
>> also there would be less objections on my part if dpb didn't try to
>> build every possible flavor, until it does. I suggest using a separate
>> security/qt-gpgme and security/gpgme
>
> This may be a good idea.
>
>> also strictly python2 and python3 flavor should default to no_qt rather
>> than with qt5. The main choice for python isn't qt5 it's Tk, and a Tk
>> flavor of gpgme would tie in with the use of python2/3.
>
> I don't understand the link between the possible -python* *subpackages*
> and qt5. Of course those subpackages shouldn't depend on Qt. We're
> talking about optional subpackages here, not package flavors.
>
>> Littering qt5 around just about everything is bad as is the whole qt
>> mind set of having to put anything and everything into it's own wrappers.
>>
>> On 11/01/17 16:53, Rafael Sadowski wrote:
>>> Hi porters,
>>>
>>> I need help with the gpgme update. Special thing here, I need the Qt
>>> bindings because kde-applications/gpgmepp is dead and all dependent
>>> programs work with gpgme-qt now.
>>>
>>> But I always trap into the following link issue:
>>>
>>> libtool: link: cc -shared -fPIC -DPIC -o
>>> .libs/libgpgme.so.20.0 -I/usr/local/include -O2 -pipe -Wall -Wcast-align
>>> -Wshadow -Wstrict-prototypes
>>> .libs/conversion.o .libs/b64dec.o .libs/get-env.o .libs/parsetlv.o
>>> .libs/mbox-util.o .libs/data.o .libs/data-fd.o .libs/data-stream.o
>>> .libs/data-mem.o .libs/data-user.o .libs/data-compat.o
>>> .libs/data-identify.o .libs/signers.o .libs/sig-notation.o
>>> .libs/wait.o .libs/wait-global.o .libs/wait-private.o
>>> .libs/wait-user.o .libs/op-support.o .libs/encrypt.o
>>> .libs/encrypt-sign.o .libs/decrypt.o .libs/decrypt-verify.o
>>> .libs/verify.o .libs/sign.o .libs/passphrase.o .libs/progress.o
>>> .libs/key.o .libs/keylist.o .libs/keysign.o .libs/trust-item.o
>>> .libs/trustlist.o .libs/tofupolicy.o .libs/import.o .libs/export.o
>>> .libs/genkey.o .libs/delete.o .libs/edit.o .libs/getauditlog.o
>>> .libs/opassuan.o .libs/passwd.o .libs/spawn.o .libs/assuan-support.o
>>> .libs/engine.o .libs/engine-gpg.o .libs/status-table.o
>>> .libs/engine-gpgsm.o .libs/engine-assuan.o .libs/engine-gpgconf.o
>>> .libs/engine-uiserver.o .libs/engine-g13.o .libs/vfs-mount.o
>>> .libs/vfs-create.o .libs/engine-spawn.o .libs/gpgconf.o
>>> .libs/queryswdb.o .libs/posix-util.o .libs/posix-io.o .libs/dirinfo.o
>>> .libs/debug.o .libs/gpgme.o .libs/version.o .libs/error.o
>>> .libs/ath.o -L.libs -lassuan -lgpg-error -lintl -liconv
>>> libtool: link: ar cru .libs/libgpgme.a conversion.o b64dec.o get-env.o
>>> parsetlv.o mbox-util.o data.o data-fd.o data-stream.o data-mem.o
>>> data-user.o data-compat.o data-identify.o signers.o sig-notation.o
>>> wait.o wait-global.o wait-private.o wait-user.o op-support.o encrypt.o
>>> encrypt-sign.o decrypt.o decrypt-verify.o verify.o sign.o passphrase.o
>>> progress.o key.o keylist.o keysign.o trust-item.o trustlist.o
>>> tofupolicy.o import.o export.o genkey.o delete.o edit.o getauditlog.o
>>> opassuan.o passwd.o spawn.o assuan-support.o engine.o engine-gpg.o
>>> status-table.o engine-gpgsm.o engine-assuan.o engine-gpgconf.o
>>> engine-uiserver.o engine-g13.o vfs-mount.o vfs-create.o engine-spawn.o
>>> gpgconf.o queryswdb.o posix-util.o posix-io.o dirinfo.o debug.o
>>> gpgme.o version.o error.o ath.o
>>> libtool: link: ranlib .libs/libgpgme.a
>>> cc -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -I/usr/local/include -O2
>>> -pipe -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT
>>> gpgme-tool.o -MD -MP -MF .deps/gpgme-tool.Tpo -c -o gpgme-tool.o
>>> gpgme-tool.c
>>> mv -f .deps/gpgme-tool.Tpo .deps/gpgme-tool.Po
>>> cc -DHAVE_CONFIG_H -I. -I.. -I/usr/local/include -I/usr/local/include
>>> -O2 -pipe -Wall -Wcast-align -Wshadow -Wstrict-prototypes -MT argparse.o
>>> -MD -MP -MF .deps/argparse.Tpo -c -o argparse.o argparse.c
>>> mv -f .deps/argparse.Tpo .deps/argparse.Po
>>> c++ gpgme-tool.o argparse.o libgpgme.la -lassuan -L/usr/local/lib
>>> -lgpg-error
>>> libgpgme.la: file not recognized: File format not recognized
>>> c++: error: linker command failed with exit code 1 (use -v to see
>>> invocation)
>
> The build should last longer if you set FLAVOR=no_qt; qt5.port.mk has
> this line:
>
> _MODQT5_SETUP += CC=cc CXX=c++ LINK_C=cc LINK=c++
>
> which breaks the libtool link. Tough luck. :)
>
> I've sent Antoine a diff to remove "LINK_C=cc LINK=c++"; maybe the whole
> line should be killed.
>
> To build both python2 and python3 at the same time you'll need such
> a hack:
>
> # XXX hack: the configure script doesn't properly handle passing
> # explicitely both python2 and python3 in --enable-languages
> post-configure:
> sed -Ei 's/^(ENABLED_LANGUAGES.*) python3/\1/' ${WRKSRC}/lang/Makefile
>
> I have a wip diff with (IMO) improvements but I have questions that
> don't have answers yet: can we afford to require a c++11 compiler for
> gpgme? How does that work in practice on !(amd64)? We definitely can't
> let gpgme have an unconditional build dep on qt5.
>
> HTH,
>
