[kde-freebsd] cad/qcad patch (was Re: [Bug 202808] [exp-run] Update Qt 4 ports to 4.8.7)

[Raphael Kubo da Costa]

(CC'ing the list again)

Ralf Nolden <nolden at kde.org> writes:
> Am Samstag, 12. September 2015, 20:09:42 schrieben Sie:
>> (Changing subject to stop mixing this with the Bugzilla thread)
>
>> Thanks for the patch. I've taken a look at it, and tried it out, and it
>> needs some improvements:
>> - It's actually missing dependencies. I'm not sure if you tried building
>>   the port inside Poudriere, but it fails at the configuration stage if
>>   you don't depend on uitools and concurrent.
> No, I didn't check it with poudriere, I just tried it out after figuring out
> how to move qt5 libs and to see if it would work with qt5. It failed with
> quazip as that was only available for qt4 and when qcad loads that lib it
> segfaults (obviously). That was the reason for checking to make two quazips,
> one which is the current and a second which is linked against qt5, installed
> in lib/qt4 and lib/qt5.
>
> Otherwise I just switched the current port to use the USE_QT5 stuff.
>
>> - `make check-plist' is broken:
>>   ===> Checking for items in pkg-plist which are not in STAGEDIR
>>   Error: Missing:
>> %%DATADIR%%/plugins/script/%%QT_LIBDIR%%qtscript_network.so.1.0.0 -
>> files/patch-support_ecmagenerator_src_srcml_RSpline.srcml needs to be
>> updated, not removed. The lines that it used to change were just moved
>> around.
>> - Just like the patches in the port make it use openNURBS from the tree
>>   instead of the bundled copy, it would probably make sense to do the
>>   same with quazip. Bundled libraries are evil.
> It does, like before - libquazip.so doesn't get installed (see pkg-plist) and
> the program depends on an installed libquazip.so (that's the reasons for my
> patches for quazip). So - it builds the bundled libquazip but doesn't ship it.

Right, I thought the libqcadzip.so part there was quazip, but it's
actually from src/zip instead.

In any case, this means that we're:
- Building the bundled quazip and producing a libquazip.so in ${WRKSRC}.
- Including the bundled quazip's headers when building other parts of
  the code.
- Linking against the _ports_ libquazip.so due to -rpath-link being
  passed to the linker. I find it odd that this is happening, and would
  likely investigate why if I had some time :)

It is more future-proof to avoid building the bundled library
altogether. For example, -rpath-link might end up not being passed in
the future, so you end up linking against one library and using another
at run-time.