<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Hi,<br>Just wanted to say I'd like to minimize dependencies for Kexi on Windows too, among other things.<br><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">With my realistic hat on, risky ideas are like: <br>- depending on kdecoration to just have default icons<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">- build-time depending on xml/docbook processing tools to just have core KF5 libs built<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">- depending on solution like dbus when native solution on given platform exist (it's a bit like linking to wine libs to use MS DDE)<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">I am afraid that unless building is easy and dependencies are reasonably minimal ('small but not smaller than possible'), quite a few 3rd-party developers will skip the 'official' KF5 and will go with forking to make it work quickly. In the best case we'd notice that code on GitHub or so. This is likely - people rarely have time to do things right; we evangelizing them to re-create feature-packed subsystem that mimics Linux infra wouldn't help. It's not _this_ kind of interest that made them interested in KF5.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">Christoph mentioned the example with sound, which sincely belongs to this group too.<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small">In kdelibs4 times even "KDE's outside world" crown jewels like Krita or Nokia mobile ports of Calligra apps had to fork/cut off large portions of kdelibs. Let's avoid that...<br></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"></div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 October 2015 at 17:54, Christoph Cullmann <span dir="ltr"><<a href="mailto:cullmann@absint.com" target="_blank">cullmann@absint.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div><div class="h5"><br>
>> I'm not sure whether it's the best solution. The problem you try to fix with<br>
>> it is distros breaking packaging. I agree with Martin K that this is a huge<br>
>> problem and that it will happen - since the automation of packages I also<br>
>> experienced that nobody looks at the output of optional dependencies and the<br>
>> packaging breaks.<br>
>><br>
>> Given that I don't think we want an ENABLE_MINIMAL_DEPENDENCIES switch, but<br>
>> rather a mode which will break if not found during distro builds.<br>
>><br>
>> Something like a "STRONGLY_RECOMMENDED" which is turned into "REQUIRED" if<br>
>> distros build (and maybe also kdesrc-build), but is optional if anybody else<br>
>> builds.<br>
>><br>
>> But I'm not sure how this could be done. Anyway, long story short: I think we<br>
>> need the other way around. It should be optional by default, but should be<br>
>> turned into stricter requirements on the linux distro case.<br>
> I would be happy with such an solution, too.<br>
> But I am not that optimistic that this is easy to achieve, how to ensure all<br>
> distros<br>
> turn this magic on?<br>
><br>
> The opposite direction at least would avoid the distro breakage and still allow<br>
> optional compiles for the "3rd party wants less dependencies" or "other platform<br>
> wants<br>
> less dependencies" use case.<br>
><br>
> Even if not optimal, some ENABLE_MINIMAL_DEPENDENCIES would in my eyes still<br>
> better than<br>
> the current situation, were either we have optional stuff that will make us<br>
> unhappy because<br>
> of broken distro packages or the devs unhappy that need to patch dependencies<br>
> out on their own.<br>
><br>
> e.g. Kåre did in most cases exactly that for the Windows build<br>
> (git@git.kde.org:scratch/sars/kate-windows),<br>
> which IMHO is sad.<br>
<br>
</div></div>My ECM proposal would be the following:<br>
<br>
1) add to KDECMakeSettings.cmake:<br>
<br>
################ Dependencies mode ####################################<br>
<br>
if(KDE_SKIP_FULL_DEPENDENCIES)<br>
    unset(KDE_FIND_REQUIRED_OR_OPTIONAL)<br>
    set(KDE_TYPE_REQUIRED_OR_OPTIONAL "OPTIONAL")<br>
else()<br>
    set(KDE_FIND_REQUIRED_OR_OPTIONAL "REQUIRED")<br>
    set(KDE_FTYPE_REQUIRED_OR_OPTIONAL "REQUIRED")<br>
endif()<br>
<br>
2) use that e.g. in knotifications:<br>
<br>
find_package(Phonon4Qt5 4.6.60 ${KDE_FIND_REQUIRED_OR_OPTIONAL} NO_MODULE)<br>
set_package_properties(Phonon4Qt5 PROPERTIES<br>
   DESCRIPTION "Qt-based audio library"<br>
   TYPE ${KDE_TYPE_REQUIRED_OR_OPTIONAL}<br>
   PURPOSE "Required to build audio notification support")<br>
<br>
That would at least make people happy that want no missing features and allow<br>
me and others to work on minimizing the dependencies without annoying others.<br>
<br>
If there is some magic way to set KDE_SKIP_FULL_DEPENDENCIES for non-distro builds,<br>
that could be added later inside KDECMakeSettings.<br>
<div class="HOEnZb"><div class="h5"><br>
Greetings<br>
Christoph<br>
<br>
--<br>
----------------------------- Dr.-Ing. Christoph Cullmann ---------<br>
AbsInt Angewandte Informatik GmbH      Email: cullmann@AbsInt.com<br>
Science Park 1                         Tel:   <a href="tel:%2B49-681-38360-22" value="+496813836022">+49-681-38360-22</a><br>
66123 Saarbrücken                      Fax:   <a href="tel:%2B49-681-38360-20" value="+496813836020">+49-681-38360-20</a><br>
GERMANY                                WWW:   <a href="http://www.AbsInt.com" rel="noreferrer" target="_blank">http://www.AbsInt.com</a><br>
--------------------------------------------------------------------<br>
Geschäftsführung: Dr.-Ing. Christian Ferdinand<br>
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234<br>
_______________________________________________<br>
Kde-frameworks-devel mailing list<br>
<a href="mailto:Kde-frameworks-devel@kde.org">Kde-frameworks-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-frameworks-devel" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kde-frameworks-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a></div>
</div>