First try at a digikam-kf5 port

[Thomas Legg]

So I've updated the port skeleton. I think it now covers all of the kf5 and
qt5 USES properly. I've also brought in the DOCS and NLS options. I've also
added the multimedia option that will do thumbnailing and playback via
qt5-multimedia. This has been tested locally with the qt5.6.1-multimedia
and is pretty dang slick. The digikam DEPENDENCIES file lists this option
as needing more testing as some earlier versions of qt5-multimedia had bugs
with gstreamer 1.0. I've yanked the gphoto2 pending some patching and
testing, but hopefully camera integration will return sooner rather than
later.

This version I feel confident enough about that I'd say it's worth a commit
pending approval of the freebsd-kde maintainers.

Thomas Legg

On Thu, Sep 1, 2016 at 4:41 PM, Tobias C. Berner <tcberner at freebsd.org>
wrote:

> Hi there
>
> I'd rather have -docs and -l10n as options than separate ports [as it is
> the same distfile] -- if at all (I don't really see a good reason not to
> install either docs or translations -- we should ship the complete thing by
> default).
>
> And then, the Makefile.common rather belongs to the kipiplugin metaport
> than to digikam itself.
>
> Yes, I think appending a -kf5 to the ports would be the right nameing
> scheme here.
> But again as with digkim,digikam-docs,digikam-l10n, I'm not sure if it is
> actually worth it to split the kipiplugins into sub-ports.
> So I would suggest to simply add a single kipiplugins-kf5 port -- you may
> choose to do it differently of course :).
>
>
> mfg Tobias
>
> On 1 September 2016 at 02:35, Thomas Legg <tjlegg at gmail.com> wrote:
>
>> Thanks for the feedback and link. I've updated the Created by line and
>> will probably push it to github when I have some time this weekend. I'm
>> also going back and looking at the makefiles for the existing kf5 ports as
>> to kde:5, kde, and qt5 options
>>
>> I think the Makefile.common will end up staying as in many ways it seems
>> to make handling the digikam-xxx-doc, digikam-xxx-l10n, the multitude of
>> kipi-pluginxx ports a bit easier. Speaking of the kipi-plugin-xxx ports,
>> none of these have a kde4 added to their name. Should I create new ports
>> with a kf5 name (kipi-plugin-imgur-kf5)? I think I probably should as it
>> looks like most of these kde4 kipi-plugins have disappeared.
>>
>> Thomas Legg
>>
>> On Tue, Aug 30, 2016 at 1:48 PM, Tobias C. Berner <tcberner at freebsd.org>
>> wrote:
>>
>>> Hi there
>>>
>>> Thanks a lot :)
>>>
>>> 1) You can modify that "Created by line" to mention you :)
>>> 2) You could probably improve that Makefile a bit, by using
>>> FOO_CMAKE_BOOL [1].
>>> 3) I'm personally also not a fan of the Makefile.common used in
>>> digikam-kde4,
>>>     and now in this one too, it makes it more confusing to me [also it
>>> contains kde4 bits].
>>>
>>> If you wan't I can import it into plasma5/PORTS :)
>>>
>>>
>>> mfg Tobias
>>>
>>>
>>> [1] https://www.freebsd.org/doc/en/books/porters-handbook/makefi
>>> le-options.html#options-cmake_bool
>>>
>>> On 29 August 2016 at 06:46, Thomas Legg <tjlegg at gmail.com> wrote:
>>>
>>>> Would love some feedback, especially on the USES, KDE, and QT5 sections
>>>> of Makefiles.
>>>> https://github.com/thomaslegg/digikam-kf5
>>>>
>>>> This builds digikam 5.1.0 built around a mutt version of the area51 kf5
>>>> branch. Mutt as I've rolled the kdepim back to 16.04 as 16.08 kdepim
>>>> calendaring requires qt5-webengine, which seems like it's going to require
>>>> a lot of work to port.
>>>>
>>>> If using digikam-kde4, I recommend moving the .db files out of your
>>>> photo repo directories and letting digikam-kde5 build new ones. I haven't
>>>> tested all of the digikam features so far, but it launches, indexes, builds
>>>> thumbnails, displays photos, adds tags. More testing required and if anyone
>>>> else gets this to build, I'd love feedback on your use.
>>>>
>>>> Thomas Legg
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-freebsd/attachments/20160903/d44c0c51/attachment.html>