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,
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
