Policy for Dependencies

[Albert Astals Cid]

El Wednesday 14 October 2015, a les 00:07:10, Jaroslaw Staniek va escriure:
> On 13 October 2015 at 23:22, Albert Astals Cid <aacid at kde.org> wrote:
> > El Tuesday 13 October 2015, a les 08:55:27, Martin Graesslin va escriure:
> > > On Tuesday, October 13, 2015 8:42:43 AM CEST Christoph Cullmann wrote:
> > > > Hi,
> > > 
> > > thanks for raising this topic. I think it's very important that we have
> > > a
> > > general strategy for frameworks and not have thousands of micro-fixes in
> > > various frameworks.
> > > 
> > > > 1) "Normal" deployment like we do in on Linux => just installing it
> > > > with
> > > > all features if possible. 2) "Application Bundles/Installer" like we
> > > > will
> > > > have to do it on Win/Mac and 3rdparty Linux people will need to do.
> > > > 
> > > > I think the easiest solution is to make stuff optional. That will
> > > > avoid
> > > > ugly "if (WIN OR APPLE OR ANDROID)".. hacks in CMake and allow people
> > > > to
> > > > still build stuff with that deps on that operating systems if really
> > > > wanted.
> > > 
> > > Given from the no-X11 fixes I think that we should avoid all if (WIN OR
> > > APPLE) as that:
> > > a) is hard to maintain
> > > b) doesn't scale
> > > c) not testable for the devs working on Linux
> > > 
> > > Given that it should be feature based and we should make as much usage
> > > of
> > > the built in CMake features we have. I really like the approach we have
> > > now
> > > found for X11 on OSX: disable certain find modules at a global level.
> > > 
> > > I think that is something which could be applied for more things.
> > > Control
> > > through global ECM settings. This could if we don't want to have global
> > > changes also through convenient command switches:
> > > 
> > > e.g. cmake -DECM_BUILD_FOR_OSX_APPBUNDLE
> > > 
> > > which then implies e.g. no phonon and no dbus and ...
> > 
> > I disagree, phonon and dbus are available on OSX and could be made to work
> > so having a ECM_BUILD_FOR_OSX_APPBUNDLE that disables perfectly valid
> > features doesn't make sense to me.
> 
> Albert,
> From the fact that some foreign solution (dbus is foreign to OSX and
> for that matter Windows) is available on these OSes one cannot
> conclude that having option not to include/use them in my OSX/Windows
> app makes no sense.

That's not what i said.

> These OSes have own solutions for sound system and desktop IPC.
> 
> Just like explorer.exe shell is perfectly valid feature delivered by a
> FOSS project wine on Linux. This does not mean I have to base file
> browsing experience for my Linux users on explorer.exe.
> 
> And have you actually read what the APPBUNDLE would mean? An OS with
> dozen of instances of dbus, each installed by one app, fighting for
> user's attention is a quite possible scenario.
> 
> Albert, if you want dbus-based workspace, there are OSes where it's
> native. I bet you can use them.
> We're talking about portable code, not portable runtimes (like Java,
> .NET, Chrome) that feel foreign/superficial on every OS.
> 
> Let's drop the desktop/workspace hat when talking about frameworks.
> Otherwise it's hard to hope that people will think about employing KF5
> to the outside world tasks -- numerous dependencies still remind them
> the "kdelibs" times of a kitchen sink approach. That wouldn't be
> honest to KF5 contributors because of man-years of great work
> invested.
> 
> Please don't stop maturing of KF5.

I hope you're not suggesting I'm against the maturing of KF5.

> 
> Christoph doing a real native port, presents a rare use case close to
> real outside world.
> 
> PS: Accept the fact that there are OSes without *rc files but
> registry. Quite close, this includes Linux+GNOME. Most probably even
> more users will uses/will use KDE software on such OSes than on the
> traditional one. I am convinced there are more Qt apps on these other
> OSes than under Linux.
> 
> Your view may be different, more workspace-related, your definition of
> portability may be different too. I am looking at code that uses KF5
> as a Qt code in the first place. Qt does not ignore design decisions
> of supported OSes, why would KF5 do this?

dbus here was just an example, as was phonon.

What i was trying to say is that having a global ECM_BUILD_FOR_OSX_APPBUNDLE 
in a framework is a bad idea since it makes the decision about the things i 
want to include in the framework binary, you either get all the features or 
none.

I should be able to decide if i want to go the extra mile adding features to 
my bundle or not in feature by feature basis, by either making things optional 
directly, or via a cmake switch.

Albert