Re: Policy for Dependencies
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 ... Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hello, On Thursday 15 October 2015 02:04:45 Aleix Pol wrote: > On Wed, Oct 14, 2015 at 10:28 PM, Kevin Ottens wrote: > > Hello, > > > > On Wednesday 14 October 2015 21:20:33 Christoph Cullmann wrote: > >> Therefore my goal for frameworks is to make them actually as easy usable > >> for people in that situation. We advertise that a lot everywhere but at > >> the > >> moment that is just not true beside for really simple stuff like > >> "karchive".> > > Just to put some historical perspective into this particular point. It > > *is* > > true, but for tier 1 and tier 2 frameworks only. That's why the dependency > > rules of the tier system were designed the way they are. > > > > So if you are "people in that situation" as described by Christoph in his > > email: stay away from anything which is above tier 2 or make it an > > optional dependency. You still have more than 30 frameworks to pick from > > for the other ones YMMV, you should be warned headaches might or might not > > be ahead with tier 3. > > > > If you are someone working on a given framework and you are just content > > of having it in KF5's tier 3, but did no refactoring or API work to get it > > to tier 2 or tier 1: you're missing the point of KF5's tier and type > > organization. You are also prematurely shrinking its potential user base > > and that should bother you, really. > > > > If you remember the talk I gave back in the days about KF5, I mentioned > > that the tier and type matrix is also a *maturity* system. It is our > > responsibility to push the frameworks down the stack as much as possible. > > Since then, I see lots of frameworks appearing, I don't see many of them > > lowering their tier... > > Would it make sense then to define as part of the tier only the > mandatory dependencies? Perhaps that's what should happen indeed. I guess there's some potential problems hiding though and it should be carefully evaluated. I also consider that as the lesser path to be honest. I much prefer some of the things we did back then with runtime detection instead for soft-dependencies. What we did to get KMessageBox down the stack is IMO what should be done at more places. Of course that can't be done everywhere (especially if API is involved). So instead of bending the rules or "just" providing compile time options to go fast, I'd rather see real thinking put into reducing the dependencies when problems arise. But hey, it's not like I'm going to do the work anyway. :-) > Then the variable could be, instead of what Christoph proposed, > something like KDE_ENFORCE_ALL_FRAMEWORKS. Orthogonal aspect IMO. See David's summary on the build system knobs. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On 2015-10-19 17:53, Christoph Cullmann wrote: On Sunday, 18 October 2015 14:45:43 BST David Faure wrote: 2) A global switch "everything that can be optional, is now optional" sounds strange to me too. If it's optional, it's optional. (The description for the suggested KDE_ENABLE_MINIMAL_DEPENDENCIES added "this might lead to a loss of functionality". Well, that is *always* true when an optional dependency isn't found - otherwise it would be useless). Really, is there any sense in saying that a dependency is optionally optional? 2.1) I can see how the purpose was to let the default build be "with as many dependencies as possible". But for that maybe we can have a global switch for "fail if something optional was not found", for distros (and CI) to make sure they have *everything* enabled. Would this actually work for distro packagers? Do they have *all* the dependencies available? I think it's more about the distinction (vague as it may be) between "optional" and "recommended" dependencies (FeatureSummary provides this distinction, but we very rarely use it). I think the idea is to be able to distinguish between "if this exists on your system, we will attempt to integrate with it" dependencies and "if we don't make use of this, a feature might be missing that users would expect to be there". (As a side note, we may have that package A depends on package B *with optional feature C*. In particular, bits of Plasma may well require or recommend that certain Frameworks are built with certain features enabled that rely on optional dependencies. This is fine - see KArchiveConfig.cmake.in for how to deal with that.) I think the idea was essentially to have an easy way to cause a build failure if the recommended dependencies weren't found (possibly with the default being the failure mode). I'm fairly on the fence about the usefulness of that, TBH, particularly if your idea below solves the "bug reports from feature-deprived builds" issue. An argument was made that optional deps create more work for maintainers, who can't know, in bug reports, whether the dep was enabled or disabled (i.e. more configurations to handle). That is true. The solution isn't however to make everything mandatory. So we should solve this, after accepting the existence of optional deps. One random idea could be (automatically) installing a file, from each framework, with the list of optional deps that were found. Then when handling bug reports you can ask for that file -- or drkonqi could grab them all and concatenate them in a readable way. This seems like a useful thing to do, especially when automating it via DrKonqi. The way KArchive does that is interesting. Would this be e.g. a way to say: Ok, we can compile configwidgets without KAuth if we skip the KCM part and then write that inside our config? Yes, you could do that, and then Plasma, for example, could check the variable that was set and complain if KConfigWidgets had been compiled without the KCM. Downstream packages could also use FeatureSummary to say something like "KFoo wasn't compiled with feature X, therefore feature Y will be disabled for this package". Atm e.g xmlgui has tremendous many dependencies that are often not needed. Boudewijn made a request to make more stuff optional which is imho a bit too intrusive but with not that much work some stuff could be removed: https://git.reviewboard.kde.org/r/125530/ I would in addition see value in a "this is recommended" switch, that leads to compile failure if recommended stuff is not there or the switch is toggled off. That way, even without David's proposed improvements for the bug reporting, I and others could make more stuff optional, like audio in notifications, without it leading to bugs for the "standard" case of distro packages. Well, this is the question: is it worth the extra complexity of supporting such a switch (and it will introduce a reasonable amount of complexity) if we have a way of including feature/dependency information in bug reports? 3) A global switch for a dependency, like "don't even look for dependency A in any of the frameworks" brings nothing IMHO. If it's optional and not found, we compile without. As in my note in (1), I don't think this is something we should be setting, but rather than builders should be setting if necessary - CMake provides all that infrastructure, so we don't need to do anything (with the exceptional case of X11 on Mac, as you noted). Yep, and btw., the way we do that at the moment for Mac is very strange. If you pass CMake no arguments, you get a strange warning that you compile without X11 support and might either turn this warning of or X11 on. I would prefer no such info at all, given non-X11 is there the only official way to go, Qt not even ships any X11 backend per default. (that you can turn it on with the var is nice, but should not be promoted) I was playing it safe, given the beha
Re: Policy for Dependencies
Hi, > On Sunday, 18 October 2015 14:45:43 BST David Faure wrote: >> On Wednesday 14 October 2015 00:33:17 Christoph Cullmann wrote: >> > Lets see what David thinks about all that. >> >> First: thanks everyone for waiting for my input, I appreciate that (I'm just >> one more voice though, no dictatorship here). > > But a well-respected voice :-). Also, you're the closest thing we have to a > "frameworks co-ordinator", in your role as release manager. Yeah ;=) > >> The various global switches that have been suggested had unintuitive naming, >> so I will describe my thinking about them by using descriptions instead of >> actual names: >> >> 1) A global switch "skip anything marked as optional" would be a very bad >> idea, it would even skip stuff that *is* available. I *think* this wasn't >> suggested, but I wanted to mention it just in case. > > There may be a certain temptation to view it as an easy solution for those who > want to build a stripped-down version of (part of) Frameworks without > accidentally dragging in deps that happen to be on the builder's system. In > practice, however, anyone doing this would probably want close control over > the deps (rather than stripping out everything optional), and CMake already > provides that via some magic variables to disable searching for packages. +1 Such a switch is not needed, if stuff is optional there are enough ways to ensure it is not used in a sane way. > >> 2) A global switch "everything that can be optional, is now optional" sounds >> strange to me too. If it's optional, it's optional. (The description for >> the suggested KDE_ENABLE_MINIMAL_DEPENDENCIES added "this might lead to a >> loss of functionality". Well, that is *always* true when an optional >> dependency isn't found - otherwise it would be useless). Really, is there >> any sense in saying that a dependency is optionally optional? >> >> 2.1) I can see how the purpose was to let the default build be "with as many >> dependencies as possible". But for that maybe we can have a global switch >> for "fail if something optional was not found", for distros (and CI) to >> make sure they have *everything* enabled. Would this actually work for >> distro packagers? Do they have *all* the dependencies available? > > I think it's more about the distinction (vague as it may be) between > "optional" and "recommended" dependencies (FeatureSummary provides this > distinction, but we very rarely use it). I think the idea is to be able to > distinguish between "if this exists on your system, we will attempt to > integrate with it" dependencies and "if we don't make use of this, a feature > might be missing that users would expect to be there". > > (As a side note, we may have that package A depends on package B *with > optional feature C*. In particular, bits of Plasma may well require or > recommend that certain Frameworks are built with certain features enabled that > rely on optional dependencies. This is fine - see KArchiveConfig.cmake.in for > how to deal with that.) > > I think the idea was essentially to have an easy way to cause a build failure > if the recommended dependencies weren't found (possibly with the default being > the failure mode). > > I'm fairly on the fence about the usefulness of that, TBH, particularly if > your idea below solves the "bug reports from feature-deprived builds" issue. > >> An argument was made that optional deps create more work for maintainers, >> who can't know, in bug reports, whether the dep was enabled or disabled >> (i.e. more configurations to handle). That is true. The solution isn't >> however to make everything mandatory. So we should solve this, after >> accepting the existence of optional deps. One random idea could be >> (automatically) installing a file, from each framework, with the list of >> optional deps that were found. Then when handling bug reports you can ask >> for that file -- or drkonqi could grab them all and concatenate them in a >> readable way. > > This seems like a useful thing to do, especially when automating it via > DrKonqi. The way KArchive does that is interesting. Would this be e.g. a way to say: Ok, we can compile configwidgets without KAuth if we skip the KCM part and then write that inside our config? Atm e.g xmlgui has tremendous many dependencies that are often not needed. Boudewijn made a request to make more stuff optional which is imho a bit too intrusive but with not that much work some stuff could be removed: https://git.reviewboard.kde.org/r/125530/ I would in addition see value in a "this is recommended" switch, that leads to compile failure if recommended stuff is not there or the switch is toggled off. That way, even without David's proposed improvements for the bug reporting, I and others could make more stuff optional, like audio in notifications, without it leading to bugs for the "standard" case of distro packages. > >> 3) A global switch for a dependency, like "don't even look for depend
Re: Policy for Dependencies
On Sunday, 18 October 2015 14:45:43 BST David Faure wrote: > On Wednesday 14 October 2015 00:33:17 Christoph Cullmann wrote: > > Lets see what David thinks about all that. > > First: thanks everyone for waiting for my input, I appreciate that (I'm just > one more voice though, no dictatorship here). But a well-respected voice :-). Also, you're the closest thing we have to a "frameworks co-ordinator", in your role as release manager. > The various global switches that have been suggested had unintuitive naming, > so I will describe my thinking about them by using descriptions instead of > actual names: > > 1) A global switch "skip anything marked as optional" would be a very bad > idea, it would even skip stuff that *is* available. I *think* this wasn't > suggested, but I wanted to mention it just in case. There may be a certain temptation to view it as an easy solution for those who want to build a stripped-down version of (part of) Frameworks without accidentally dragging in deps that happen to be on the builder's system. In practice, however, anyone doing this would probably want close control over the deps (rather than stripping out everything optional), and CMake already provides that via some magic variables to disable searching for packages. > 2) A global switch "everything that can be optional, is now optional" sounds > strange to me too. If it's optional, it's optional. (The description for > the suggested KDE_ENABLE_MINIMAL_DEPENDENCIES added "this might lead to a > loss of functionality". Well, that is *always* true when an optional > dependency isn't found - otherwise it would be useless). Really, is there > any sense in saying that a dependency is optionally optional? > > 2.1) I can see how the purpose was to let the default build be "with as many > dependencies as possible". But for that maybe we can have a global switch > for "fail if something optional was not found", for distros (and CI) to > make sure they have *everything* enabled. Would this actually work for > distro packagers? Do they have *all* the dependencies available? I think it's more about the distinction (vague as it may be) between "optional" and "recommended" dependencies (FeatureSummary provides this distinction, but we very rarely use it). I think the idea is to be able to distinguish between "if this exists on your system, we will attempt to integrate with it" dependencies and "if we don't make use of this, a feature might be missing that users would expect to be there". (As a side note, we may have that package A depends on package B *with optional feature C*. In particular, bits of Plasma may well require or recommend that certain Frameworks are built with certain features enabled that rely on optional dependencies. This is fine - see KArchiveConfig.cmake.in for how to deal with that.) I think the idea was essentially to have an easy way to cause a build failure if the recommended dependencies weren't found (possibly with the default being the failure mode). I'm fairly on the fence about the usefulness of that, TBH, particularly if your idea below solves the "bug reports from feature-deprived builds" issue. > An argument was made that optional deps create more work for maintainers, > who can't know, in bug reports, whether the dep was enabled or disabled > (i.e. more configurations to handle). That is true. The solution isn't > however to make everything mandatory. So we should solve this, after > accepting the existence of optional deps. One random idea could be > (automatically) installing a file, from each framework, with the list of > optional deps that were found. Then when handling bug reports you can ask > for that file -- or drkonqi could grab them all and concatenate them in a > readable way. This seems like a useful thing to do, especially when automating it via DrKonqi. > 3) A global switch for a dependency, like "don't even look for dependency A > in any of the frameworks" brings nothing IMHO. If it's optional and not > found, we compile without. As in my note in (1), I don't think this is something we should be setting, but rather than builders should be setting if necessary - CMake provides all that infrastructure, so we don't need to do anything (with the exceptional case of X11 on Mac, as you noted). Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Wednesday 14 October 2015 00:33:17 Christoph Cullmann wrote: > > Lets see what David thinks about all that. First: thanks everyone for waiting for my input, I appreciate that (I'm just one more voice though, no dictatorship here). The various global switches that have been suggested had unintuitive naming, so I will describe my thinking about them by using descriptions instead of actual names: 1) A global switch "skip anything marked as optional" would be a very bad idea, it would even skip stuff that *is* available. I *think* this wasn't suggested, but I wanted to mention it just in case. 2) A global switch "everything that can be optional, is now optional" sounds strange to me too. If it's optional, it's optional. (The description for the suggested KDE_ENABLE_MINIMAL_DEPENDENCIES added "this might lead to a loss of functionality". Well, that is *always* true when an optional dependency isn't found - otherwise it would be useless). Really, is there any sense in saying that a dependency is optionally optional? :-P 2.1) I can see how the purpose was to let the default build be "with as many dependencies as possible". But for that maybe we can have a global switch for "fail if something optional was not found", for distros (and CI) to make sure they have *everything* enabled. Would this actually work for distro packagers? Do they have *all* the dependencies available? The discussion on 2) vs 2.1) is almost like discussing the default value of the same option, except that with 2) every framework would still be able to have always-required, required-or-optional, and always-optional dependencies. You could say that's extremely flexible, on the other hand I wonder if it's not too much choice (i.e. too much complexity). E.g. the kwallet dependency in KIO now is optional, therefore it's optional, end of story. Yet we don't want distros compiling KIO without KWallet, but aren't we optimizing for the wrong thing? I mean, I didn't hear about KF5 packages being wrong because of missing deps (i.e. if it happened, it must have been fixed pretty quickly). So unless someone proves the contrary to me, I would say this whole 2/2.1 discussion is moot, the tools that we have (to express optional dependencies) do work, we just need to work towards making more stuff optional, like Christoph is doing. An argument was made that optional deps create more work for maintainers, who can't know, in bug reports, whether the dep was enabled or disabled (i.e. more configurations to handle). That is true. The solution isn't however to make everything mandatory. So we should solve this, after accepting the existence of optional deps. One random idea could be (automatically) installing a file, from each framework, with the list of optional deps that were found. Then when handling bug reports you can ask for that file -- or drkonqi could grab them all and concatenate them in a readable way. 3) A global switch for a dependency, like "don't even look for dependency A in any of the frameworks" brings nothing IMHO. If it's optional and not found, we compile without. 3.1) As a special case of that, I do however see the usefulness of "don't even look for X11" as a global switch, because of the OSX case where it might be lying around and we don't want to use it. It's a special case because it's an exclusive switch (AFAIK you either use cocoa or X11, not both), unlike most of our other dependencies. 3.2) More generally *if* distributors want a way to express "don't even look for dependency A, because I might have it installed but I don't want my packages to depend on it", then I have nothing against that. And then the X11 case can be just one instance of that. I'm not replying here to the part of the thread around packaging for Windows and Mac, that's a separate discussion. I note, however, that Christoph's patches which make more use of .qrc files, are the best way to solve some of these issues. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi,
I have now all my patches in frameworks to build some KWrite/Kate application
bundle that doesn't instantly crash (and windows builds seem to be nicer, too,
without that many problems to locate assets).
My last patch missing makes still stuff optional:
https://git.reviewboard.kde.org/r/125616/
Could we come up with some "have a global switch in ECM or not" and if not,
how to do such things?
Greetings
Christoph
- Am 14. Okt 2015 um 16:03 schrieb Alex Merry alex.me...@kde.org:
> On 2015-10-13 16:54, Christoph Cullmann wrote:
>> Hi,
>>
I'm not sure whether it's the best solution. The problem you try to
fix with
it is distros breaking packaging. I agree with Martin K that this is
a huge
problem and that it will happen - since the automation of packages I
also
experienced that nobody looks at the output of optional dependencies
and the
packaging breaks.
Given that I don't think we want an ENABLE_MINIMAL_DEPENDENCIES
switch, but
rather a mode which will break if not found during distro builds.
Something like a "STRONGLY_RECOMMENDED" which is turned into
"REQUIRED" if
distros build (and maybe also kdesrc-build), but is optional if
anybody else
builds.
But I'm not sure how this could be done. Anyway, long story short: I
think we
need the other way around. It should be optional by default, but
should be
turned into stricter requirements on the linux distro case.
>>> I would be happy with such an solution, too.
>>> But I am not that optimistic that this is easy to achieve, how to
>>> ensure all
>>> distros
>>> turn this magic on?
>>>
>>> The opposite direction at least would avoid the distro breakage and
>>> still allow
>>> optional compiles for the "3rd party wants less dependencies" or
>>> "other platform
>>> wants
>>> less dependencies" use case.
>>>
>>> Even if not optimal, some ENABLE_MINIMAL_DEPENDENCIES would in my eyes
>>> still
>>> better than
>>> the current situation, were either we have optional stuff that will
>>> make us
>>> unhappy because
>>> of broken distro packages or the devs unhappy that need to patch
>>> dependencies
>>> out on their own.
>>>
>>> e.g. Kåre did in most cases exactly that for the Windows build
>>> (g...@git.kde.org:scratch/sars/kate-windows),
>>> which IMHO is sad.
>>
>> My ECM proposal would be the following:
>>
>> 1) add to KDECMakeSettings.cmake:
>>
>> Dependencies mode
>>
>> if(KDE_SKIP_FULL_DEPENDENCIES)
>> unset(KDE_FIND_REQUIRED_OR_OPTIONAL)
>> set(KDE_TYPE_REQUIRED_OR_OPTIONAL "OPTIONAL")
>> else()
>> set(KDE_FIND_REQUIRED_OR_OPTIONAL "REQUIRED")
>> set(KDE_FTYPE_REQUIRED_OR_OPTIONAL "REQUIRED")
>> endif()
>>
>> 2) use that e.g. in knotifications:
>>
>> find_package(Phonon4Qt5 4.6.60 ${KDE_FIND_REQUIRED_OR_OPTIONAL}
>> NO_MODULE)
>> set_package_properties(Phonon4Qt5 PROPERTIES
>>DESCRIPTION "Qt-based audio library"
>>TYPE ${KDE_TYPE_REQUIRED_OR_OPTIONAL}
>>PURPOSE "Required to build audio notification support")
>>
>> That would at least make people happy that want no missing features and
>> allow
>> me and others to work on minimizing the dependencies without annoying
>> others.
>>
>> If there is some magic way to set KDE_SKIP_FULL_DEPENDENCIES for
>> non-distro builds,
>> that could be added later inside KDECMakeSettings.
>
> I'm not a fan of the variable names - in particular, I think your
> original idea for an option name was better than
> "KDE_SKIP_FULL_DEPENDENCIES" - the existing KDE_SKIP_* variables are
> meant as things project authors define if they only want part of the
> module functionality, rather than as something for users/packagers to
> set. KDE_FIND_REQUIRED_OR_OPTIONAL also tells me essentially nothing
> about *why* it might be REQUIRED or optional when I'm reading the
> source.
>
> That said, I'm on board with the overall idea.
>
> Alex
>
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
--
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com
Science Park 1 Tel: +49-681-38360-22
66123 Saarbrücken Fax: +49-681-38360-20
GERMANYWWW: http://www.AbsInt.com
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On 14 October 2015 at 20:55, Boudewijn Rempt wrote:
> On Wed, 14 Oct 2015, Martin Klapetek wrote:
>
>> On Wed, Oct 14, 2015 at 1:38 PM, Christoph Cullmann
>> wrote:
>>
>> Given that lot opposition was here for a 5 lines change which does
>> break nothing
>> if packagers don't skrew up.
>>
>>
>> Not to be disrespectful, but history has proven that the assumption
>> above unfortunately doesn't always hold up. So it's just better not
>> to count on it. Hence so much of the opposition.
>>
>
> Well, sure, stuff can break. However, without changes like this, KDE's
> Frameworks libraries are _not fit for purpose_. These libraries _can not
> be used_ by the intended user group, that is application developers,
> except for the tiny minority that only targets Linux, and only cares
> about having their applications packaged by distributions. As for Krita,
> we currently maintain builds for three distributions, and I can't wait
> for the day we can have a generic linux build like Blender and Firefox.
>
And LO.
Yes, I hope it's easy to see the pattern. And some of us may remember
the internal thread from this month about challenges Calligra faces to
win users.
Deployment is rather important part of this.
Let me CC kde-windows too. The topic seems to fit to many places.
When Ubuntu introduced the LTS it started to beat us heavily. "I am
not using your software because for ${some} reason I am bound to LTS"
See just the newest request as a sample:
http://permalink.gmane.org/gmane.comp.kde.users.kexi/833
Customers^w Users are always right.
So yes, a practical approach to deployment on Linux is not too
different than the one on the Windows/Mac/99.(9)% of mobile.
People that are forced to use given app will even install a VM to do
so. Compare size of the copied libs to the size of VM...
Compare to the size of the apps installed on your smartphone...
One way how we could "integrate" deployment of apps is for the case
when multiple apps are keeping their KF5 stuff in one place such as:
C:\ProgramFiles\Common Files\KDE\KF5\{some-timestamp}
Speculation: Multiple versions could be present there, identified by a
strong {some-timestamp} ID. And installers shall be in a form of Qt
Installer ("web" installers able to add shared components). It would
be then up to people manage deployments of a given application to
manage KF5 version that is known to work the app. Technical challenge
is here that the KF5\{some-timestamp} dir belongs to application. And
that one app may just install, say, 30% of KF5, another may install
70% of it. That looks like too complex and boring to manage by us,
volunteers.
So for Windows, having the C:\ProgramFiles\Common Files\KDE\ used for
a root dir of private copies of KDE stuff (including KF5) would be
better than nothing.
But on the risk side is that someone would think the subdirs are there
to reuse. That's not true because back/forward compatibility is not
part of these components. They are bound to given app(s) (one app or
entire Calligra for example).
No clear solution here then. Being a fan of native solutions (services
native to the OS), and sp the principle of the least-surprise, I am
thus not fan of exposing of software collections via the KDE-Installer
on Windows or equivalents on Mac. I'd like to make sure that anyone
who wants to package a KF5/Qt app separately can do that freely,
strip-down things conveniently in a way we accept, and there won't be
conflict with other installations. And that the packaged app won't be
perceived as "unofficial" because of the way of deployment. Freedom of
deploying alternatives away of the official channel - that IMHO boosts
competition and non-forced cooperation - something many of us see
missing in iOS.
I trust that whenever contributors discover it's "cheaper" to join KDE
than staying on the custom side, they will be joining. I see that
would be a big win-win.
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi, - Aleix Pol schrieb: > On We > Would it make sense then to define as part of the tier only the > mandatory dependencies? > > Then the variable could be, instead of what Christoph proposed, > something like KDE_ENFORCE_ALL_FRAMEWORKS. For my usecase that wont help, as i want to make non-framework dependencies optional, too, like phonon. Greetings Christoph > > Aleix > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Wed, Oct 14, 2015 at 10:28 PM, Kevin Ottens wrote: > Hello, > > On Wednesday 14 October 2015 21:20:33 Christoph Cullmann wrote: >> Therefore my goal for frameworks is to make them actually as easy usable >> for people in that situation. We advertise that a lot everywhere but at the >> moment that is just not true beside for really simple stuff like "karchive". > > Just to put some historical perspective into this particular point. It *is* > true, but for tier 1 and tier 2 frameworks only. That's why the dependency > rules of the tier system were designed the way they are. > > So if you are "people in that situation" as described by Christoph in his > email: stay away from anything which is above tier 2 or make it an optional > dependency. You still have more than 30 frameworks to pick from for the other > ones YMMV, you should be warned headaches might or might not be ahead with > tier 3. > > If you are someone working on a given framework and you are just content of > having it in KF5's tier 3, but did no refactoring or API work to get it to > tier 2 or tier 1: you're missing the point of KF5's tier and type > organization. You are also prematurely shrinking its potential user base and > that should bother you, really. > > If you remember the talk I gave back in the days about KF5, I mentioned that > the tier and type matrix is also a *maturity* system. It is our responsibility > to push the frameworks down the stack as much as possible. Since then, I see > lots of frameworks appearing, I don't see many of them lowering their tier... > > Regards. Would it make sense then to define as part of the tier only the mandatory dependencies? Then the variable could be, instead of what Christoph proposed, something like KDE_ENFORCE_ALL_FRAMEWORKS. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hello, On Wednesday 14 October 2015 21:20:33 Christoph Cullmann wrote: > Therefore my goal for frameworks is to make them actually as easy usable > for people in that situation. We advertise that a lot everywhere but at the > moment that is just not true beside for really simple stuff like "karchive". Just to put some historical perspective into this particular point. It *is* true, but for tier 1 and tier 2 frameworks only. That's why the dependency rules of the tier system were designed the way they are. So if you are "people in that situation" as described by Christoph in his email: stay away from anything which is above tier 2 or make it an optional dependency. You still have more than 30 frameworks to pick from for the other ones YMMV, you should be warned headaches might or might not be ahead with tier 3. If you are someone working on a given framework and you are just content of having it in KF5's tier 3, but did no refactoring or API work to get it to tier 2 or tier 1: you're missing the point of KF5's tier and type organization. You are also prematurely shrinking its potential user base and that should bother you, really. If you remember the talk I gave back in the days about KF5, I mentioned that the tier and type matrix is also a *maturity* system. It is our responsibility to push the frameworks down the stack as much as possible. Since then, I see lots of frameworks appearing, I don't see many of them lowering their tier... Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
I'd like to weigh in a bit here too. I agree with Boud and Christoph, most users (developers of applications) of KF5 that aren't KDE community members will be building the frameworks themselves. At my last job we built Qt ourselves on all the platforms we targetted and shipped shared libraries with the application like Boud has said. We even had scripts that would set LD_LIBRARY_PATH to the application folder so our Qt was preferred over any system Qt for linux. I also agree with what Martin said a few emails ago. Applications we are distributing on non kde platforms (or maybe even when running them on GNOME?) should probably not use knotifications, etc. Though that would remove a bit of their functionality. Personally I'd like to see stuff like knewstuff working on windows/mac, but can't imagine it will since it uses kio heavily (and thus needs kdeinit, etc.). I think the more modular we can get the KDE Frameworks the better. BR, Jeremy On Wed, Oct 14, 2015 at 1:51 PM, Boudewijn Rempt wrote: > On Wed, 14 Oct 2015, Martin Klapetek wrote: > >> I have to agree with Harald here though, I would also expect >> the frameworks to be bunch of pre-built dlls you just install >> system-wide and build on top of that, not create your own >> custom builds of everything, for every app with different features >> combo. At which point this all wouldn't be so much of a problem >> I believe. > > > Erm... The very _idea_ that you'd install a bunch of dll's system-wide > on Windows or OSX or Android is... Words, at least, polite words, fail > me. It's not just not done, it's actively wrong. (Note that ministro's > way of doing shared Qt libraries no longer works in the most recent Android > either, it's not a counter example.) > > I've been trying to get this point across at least since the desktop > summit in berlin, and I guess I'm just congenitally incapable of stringing > words together into an intelligible narrative because I'm failing _hard_. > > Fink, macports, emerge, cygwin and all the other refuges for Linux > developers who have to use Windows or decide to defect to OSX are totally > and utterly irrelevant. If you want to make a library that's used for a > cross-platform application, that is. > > There is _one_ way to package your application for Windows, and that is > create an installer that packages everything, every dependency that the > application needs _including_ the msv c runtime dll. Everything else > will not get your application in your user's hands. > > There are _two_ ways to package your application for OSX: as an app bundle > in a disk image or as an app bundle in an installer. The app bundle > contains all dependencies, everything, except for the stuff Apple puts > on the system. Everything else will not get your application in your > user's hands. > > Any approach that dreams of sharing libraries, configuration locations or > _any_ other resource not provided by the OS among multiple applications > will not get that library used by applications that target Windows or OSX. > > Now, re-using and re-packaging pre-built dll's _is_ possible. It's > sometimes, as with fftw3, even the only realistic option. But it would > still put that dll in the exe dir of every application that uses it. And, > with complex libraries, it's still not going to work. I use a bunch of > cmake external projects to build all the deps, so I can cut down on what's > in there, for instance, and I should cut even more than I'm already doing. > > Boudewijn > > Ps: there are three ways of packaging an app on Linux: let the distribution > do it, and fight with your users because they cannot get the latest version, > package it yourself for each popular distro (in my case, *buntu, CentOS and > OpenSUSE) or make a distro-independent package, which every big open source > project does, like Blender or Firefox. In the last case, you'll again have > to package everything, like on Windows and OSX. > > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Wed, 14 Oct 2015, Martin Klapetek wrote: I have to agree with Harald here though, I would also expect the frameworks to be bunch of pre-built dlls you just install system-wide and build on top of that, not create your own custom builds of everything, for every app with different features combo. At which point this all wouldn't be so much of a problem I believe. Erm... The very _idea_ that you'd install a bunch of dll's system-wide on Windows or OSX or Android is... Words, at least, polite words, fail me. It's not just not done, it's actively wrong. (Note that ministro's way of doing shared Qt libraries no longer works in the most recent Android either, it's not a counter example.) I've been trying to get this point across at least since the desktop summit in berlin, and I guess I'm just congenitally incapable of stringing words together into an intelligible narrative because I'm failing _hard_. Fink, macports, emerge, cygwin and all the other refuges for Linux developers who have to use Windows or decide to defect to OSX are totally and utterly irrelevant. If you want to make a library that's used for a cross-platform application, that is. There is _one_ way to package your application for Windows, and that is create an installer that packages everything, every dependency that the application needs _including_ the msv c runtime dll. Everything else will not get your application in your user's hands. There are _two_ ways to package your application for OSX: as an app bundle in a disk image or as an app bundle in an installer. The app bundle contains all dependencies, everything, except for the stuff Apple puts on the system. Everything else will not get your application in your user's hands. Any approach that dreams of sharing libraries, configuration locations or _any_ other resource not provided by the OS among multiple applications will not get that library used by applications that target Windows or OSX. Now, re-using and re-packaging pre-built dll's _is_ possible. It's sometimes, as with fftw3, even the only realistic option. But it would still put that dll in the exe dir of every application that uses it. And, with complex libraries, it's still not going to work. I use a bunch of cmake external projects to build all the deps, so I can cut down on what's in there, for instance, and I should cut even more than I'm already doing. Boudewijn Ps: there are three ways of packaging an app on Linux: let the distribution do it, and fight with your users because they cannot get the latest version, package it yourself for each popular distro (in my case, *buntu, CentOS and OpenSUSE) or make a distro-independent package, which every big open source project does, like Blender or Firefox. In the last case, you'll again have to package everything, like on Windows and OSX. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi, > Well, sure, stuff can break. However, without changes like this, KDE's > Frameworks libraries are _not fit for purpose_. These libraries _can not > be used_ by the intended user group, that is application developers, > except for the tiny minority that only targets Linux, and only cares > about having their applications packaged by distributions. As for Krita, > we currently maintain builds for three distributions, and I can't wait > for the day we can have a generic linux build like Blender and Firefox. > > I've talked myself hoarse selling frameworks to dozens of interested > people at the QtWS in Berlin, none of whom cared about how Linux > distributions would package their software, but I'm honestly going to have > to copy a bunch of code and cut it down, instead of using the libraries > them- selves. Claiming, as people have done in the past, that that's > because my attitude is bad or because I refuse to do the right thing > is wrong-headed. People who make a library must make it fit for use, > and not demand that their target users adapt or skip using it. > > I have to agree with Harald here though, I would also expect > the frameworks to be bunch of pre-built dlls you just install > system-wide and build on top of that, not create your own > custom builds of everything, for every app with different features > combo. At which point this all wouldn't be so much of a problem > I believe. Sorry, that is more than unrealistic ;=) I am now around 10 years maintaining both the continous integration system and the packaging of our applications at the company for Linux + Windows and no, you can't even rely on having a global Qt around on your target and you install no libraries system wide, that just cries for problems. Any non-distro package will need to ship the libs on its own and it will need to compile them on its own, as you need to have the right libs around for exactly your compiler (on windows even more so than on mac, no, no visual studio version is compatible and you actually want even to use the same patch level/hotfix/CTP/...) That might be not nice, but that is the reality. If the current trend of "we use containers for everything" continues, you will even more or less ship half a system with your thingy in that container ;=) At the moment for us that means, we ship a own shared library Qt. If we want to use some frameworks, we will need to build + ship them, too. Same hold for other people doing "standalone" applications, even free ones like Krita. And yes, it is a hassle and it is work I could really be happy to get off my hands but I doubt a magic solution will arrive. Therefore my goal for frameworks is to make them actually as easy usable for people in that situation. We advertise that a lot everywhere but at the moment that is just not true beside for really simple stuff like "karchive". But back to my proposal. Alex Merry seems to be ok with the idea, thought my variable name choice is bad ;=) Lets see if David agrees, too, then I would like to move forward with this, if that would be alright. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Wed, Oct 14, 2015 at 2:55 PM, Boudewijn Rempt wrote: > > Well, sure, stuff can break. However, without changes like this, KDE's > Frameworks libraries are _not fit for purpose_. These libraries _can not > be used_ by the intended user group, that is application developers, > except for the tiny minority that only targets Linux, and only cares > about having their applications packaged by distributions. As for Krita, > we currently maintain builds for three distributions, and I can't wait > for the day we can have a generic linux build like Blender and Firefox. > > I've talked myself hoarse selling frameworks to dozens of interested > people at the QtWS in Berlin, none of whom cared about how Linux > distributions would package their software, but I'm honestly going to have > to copy a bunch of code and cut it down, instead of using the libraries > them- selves. Claiming, as people have done in the past, that that's > because my attitude is bad or because I refuse to do the right thing > is wrong-headed. People who make a library must make it fit for use, > and not demand that their target users adapt or skip using it. I have to agree with Harald here though, I would also expect the frameworks to be bunch of pre-built dlls you just install system-wide and build on top of that, not create your own custom builds of everything, for every app with different features combo. At which point this all wouldn't be so much of a problem I believe. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Wed, 14 Oct 2015, Martin Klapetek wrote: On Wed, Oct 14, 2015 at 1:38 PM, Christoph Cullmann wrote: Given that lot opposition was here for a 5 lines change which does break nothing if packagers don't skrew up. Not to be disrespectful, but history has proven that the assumption above unfortunately doesn't always hold up. So it's just better not to count on it. Hence so much of the opposition. Well, sure, stuff can break. However, without changes like this, KDE's Frameworks libraries are _not fit for purpose_. These libraries _can not be used_ by the intended user group, that is application developers, except for the tiny minority that only targets Linux, and only cares about having their applications packaged by distributions. As for Krita, we currently maintain builds for three distributions, and I can't wait for the day we can have a generic linux build like Blender and Firefox. I've talked myself hoarse selling frameworks to dozens of interested people at the QtWS in Berlin, none of whom cared about how Linux distributions would package their software, but I'm honestly going to have to copy a bunch of code and cut it down, instead of using the libraries them- selves. Claiming, as people have done in the past, that that's because my attitude is bad or because I refuse to do the right thing is wrong-headed. People who make a library must make it fit for use, and not demand that their target users adapt or skip using it. Boudewijn ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
El Wednesday 14 October 2015, a les 16:44:12, Boudewijn Rempt va escriure: > On Tue, 13 Oct 2015, Albert Astals Cid wrote: > > 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. > > But what if those things don't add any feature to a particularly app? > There's nothing that phonon or dbus or openssl actually add to an > application like Krita. As I already explained in a different email, if you want to disable them cool, that's not what i was arguing against, please see the other email for what i was trying to say. Cheers, Albert > > Boudewijn > ___ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Wed, Oct 14, 2015 at 1:38 PM, Christoph Cullmann wrote: > > Given that lot opposition was here for a 5 lines change which does break > nothing > if packagers don't skrew up. > Not to be disrespectful, but history has proven that the assumption above unfortunately doesn't always hold up. So it's just better not to count on it. Hence so much of the opposition. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi, > Fwiw, KNotification+Phonon is used for KDialog sounds if frameworkintegration > is present (iirc). So in theory, it should play a sound in Krita/Kate if you > eg. > close > the window with unsaved content. If that adds anything to your app, I can't > say. > > > ^That's supposed to be KMessageBox, not KDialog, sorry. > > Well, no, nothing materially useful, sorry. If all messageboxes on > Windows or OSX would beep, then Krita's message boxes should beep, > much as I feel that computers shoulds be seen, not heard, but then, > that would be the responsibility of Qt, as the cross-platform layer. > It should be part of QMessageBox, not be added through an optional > extra library. > > But then it makes me wonder if you actually need KNotifications altogether. > I'm not aware of anyone actually testing KNotificaitons on win/mac and I > personally wouldn't guarantee it works at all on !linux. > > Same for Kate - do you actually need KNotifications at all on win/mac? > If not, it would be better to just drop that dep from Kate/Krita/whatever > than split KNotifications package which isn't used anyway. yeah, perhaps that is the next step, but not Kate depends on it but KParts. And yeah, there is a lot of stuff that could be made optional there, too. But I want first to have the "how to do it right", then I will do it. Given that lot opposition was here for a 5 lines change which does break nothing if packagers don't skrew up. I am more than happy to try to minimize the deps even more, but first, I really would like to have a base line that works. e.g. dbus: ATM I don't even try to compile without it, but just try to make things not crash if we compile with it but have no dbus server running. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Wed, 14 Oct 2015, Martin Klapetek wrote: But then it makes me wonder if you actually need KNotifications altogether. I'm not aware of anyone actually testing KNotificaitons on win/mac and I personally wouldn't guarantee it works at all on !linux. Same for Kate - do you actually need KNotifications at all on win/mac? If not, it would be better to just drop that dep from Kate/Krita/whatever than split KNotifications package which isn't used anyway. Well, there's that, and I don't think we build against knotifications at the moment, and in any case, our windows/osx build is pretty immature. My own bete noir at the moment is kxmlgui, which needs kconfigwidgets, which needs kauth and codecs, but it's kind of the general way of things: if there's a library I need that links to knotification, either that link should be optional, or knotification should be more modular. Boudewijn ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Wed, Oct 14, 2015 at 1:27 PM, Boudewijn Rempt wrote: > On Wed, 14 Oct 2015, Martin Klapetek wrote: > > Fwiw, KNotification+Phonon is used for KDialog sounds if >> frameworkintegration >> is present (iirc). So in theory, it should play a sound in Krita/Kate if >> you eg. close >> the window with unsaved content. If that adds anything to your app, I >> can't say. >> >> >> ^That's supposed to be KMessageBox, not KDialog, sorry. >> > > Well, no, nothing materially useful, sorry. If all messageboxes on > Windows or OSX would beep, then Krita's message boxes should beep, > much as I feel that computers shoulds be seen, not heard, but then, > that would be the responsibility of Qt, as the cross-platform layer. > It should be part of QMessageBox, not be added through an optional > extra library. But then it makes me wonder if you actually need KNotifications altogether. I'm not aware of anyone actually testing KNotificaitons on win/mac and I personally wouldn't guarantee it works at all on !linux. Same for Kate - do you actually need KNotifications at all on win/mac? If not, it would be better to just drop that dep from Kate/Krita/whatever than split KNotifications package which isn't used anyway. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Wed, 14 Oct 2015, Martin Klapetek wrote: Fwiw, KNotification+Phonon is used for KDialog sounds if frameworkintegration is present (iirc). So in theory, it should play a sound in Krita/Kate if you eg. close the window with unsaved content. If that adds anything to your app, I can't say. ^That's supposed to be KMessageBox, not KDialog, sorry. Well, no, nothing materially useful, sorry. If all messageboxes on Windows or OSX would beep, then Krita's message boxes should beep, much as I feel that computers shoulds be seen, not heard, but then, that would be the responsibility of Qt, as the cross-platform layer. It should be part of QMessageBox, not be added through an optional extra library. Boudewijn ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Wed, Oct 14, 2015 at 10:44 AM, Boudewijn Rempt wrote: > On Tue, 13 Oct 2015, Albert Astals Cid wrote: > > 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. >> > > But what if those things don't add any feature to a particularly app? > There's > nothing that phonon or dbus or openssl actually add to an application like > Krita. Fwiw, KNotification+Phonon is used for KDialog sounds if frameworkintegration is present (iirc). So in theory, it should play a sound in Krita/Kate if you eg. close the window with unsaved content. If that adds anything to your app, I can't say. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi, > 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. > > But what if those things don't add any feature to a particularly app? There's > nothing that phonon or dbus or openssl actually add to an application like > Krita. > > Fwiw, KNotification+Phonon is used for KDialog sounds if frameworkintegration > is present (iirc). So in theory, it should play a sound in Krita/Kate if you > eg. > close > the window with unsaved content. If that adds anything to your app, I can't > say. > > ^That's supposed to be KMessageBox, not KDialog, sorry. ;=) Yeah, and thats a valid thing to have. Therefore I don't want to hard "forbid audio for bundling or for mac/win" but just an weak "make it optional" to make it easy for people that want that audio feedback to build it with and bundle it with such support. Like people can just bundle QtSpeech stuff just fine, if they want, but are not required to do so ;=) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Wed, Oct 14, 2015 at 10:49 AM, Martin Klapetek wrote: > On Wed, Oct 14, 2015 at 10:44 AM, Boudewijn Rempt > wrote: > >> On Tue, 13 Oct 2015, Albert Astals Cid wrote: >> >> 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. >>> >> >> But what if those things don't add any feature to a particularly app? >> There's >> nothing that phonon or dbus or openssl actually add to an application like >> Krita. > > > Fwiw, KNotification+Phonon is used for KDialog sounds if > frameworkintegration > is present (iirc). So in theory, it should play a sound in Krita/Kate if > you eg. close > the window with unsaved content. If that adds anything to your app, I > can't say. > ^That's supposed to be KMessageBox, not KDialog, sorry. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Tue, 13 Oct 2015, Albert Astals Cid wrote: 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. But what if those things don't add any feature to a particularly app? There's nothing that phonon or dbus or openssl actually add to an application like Krita. Boudewijn ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Tue, 13 Oct 2015, Christoph Cullmann wrote: I think we must accept, that on neither Windows nor Mac we will have all dependencies available and that for many applications not all features are needed. There is no "packagers" for that operating systems, you need to provide the stuff you use yourself, just like you would do on Android/iOS. E.g. no, I doubt that Krita or Kate will suffer a lot, if we have no sound, nor will many 3rdparty applications. We can make the knotifications usage more optional, e.g. in kparts, or we can make the knotifications dependencies more optional. I'll go further, and say that I simply don't want any dll's that aren't actually adding a feature to Krita in my packages. I'm even building Qt myself to get rid of things like dbus and openssl. Therefore I think less dependencies are needed to be called "portable" in that case. But that a side, for the dependencies itself, no matter if we target just one os or multiple, would the KDE_ENABLE_MINIMAL_DEPENDENCIES switch be a solution for the criticism raised? That's really close to what I used to do with kdelibs4 and koffice/calligra. I created a switch like that and had it cut out everything that wasn't needed. The kdelibs always remained in my fork; I never tried to upstream it since it was really hacky. The calligra switch was public. In practice, it didn't give problems for Linux because distributions always build with all dependencies enabled, they wouldn't go and add -DTINY=ON. Boudewijn ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On 2015-10-13 16:54, Christoph Cullmann wrote:
Hi,
I'm not sure whether it's the best solution. The problem you try to
fix with
it is distros breaking packaging. I agree with Martin K that this is
a huge
problem and that it will happen - since the automation of packages I
also
experienced that nobody looks at the output of optional dependencies
and the
packaging breaks.
Given that I don't think we want an ENABLE_MINIMAL_DEPENDENCIES
switch, but
rather a mode which will break if not found during distro builds.
Something like a "STRONGLY_RECOMMENDED" which is turned into
"REQUIRED" if
distros build (and maybe also kdesrc-build), but is optional if
anybody else
builds.
But I'm not sure how this could be done. Anyway, long story short: I
think we
need the other way around. It should be optional by default, but
should be
turned into stricter requirements on the linux distro case.
I would be happy with such an solution, too.
But I am not that optimistic that this is easy to achieve, how to
ensure all
distros
turn this magic on?
The opposite direction at least would avoid the distro breakage and
still allow
optional compiles for the "3rd party wants less dependencies" or
"other platform
wants
less dependencies" use case.
Even if not optimal, some ENABLE_MINIMAL_DEPENDENCIES would in my eyes
still
better than
the current situation, were either we have optional stuff that will
make us
unhappy because
of broken distro packages or the devs unhappy that need to patch
dependencies
out on their own.
e.g. Kåre did in most cases exactly that for the Windows build
(g...@git.kde.org:scratch/sars/kate-windows),
which IMHO is sad.
My ECM proposal would be the following:
1) add to KDECMakeSettings.cmake:
Dependencies mode
if(KDE_SKIP_FULL_DEPENDENCIES)
unset(KDE_FIND_REQUIRED_OR_OPTIONAL)
set(KDE_TYPE_REQUIRED_OR_OPTIONAL "OPTIONAL")
else()
set(KDE_FIND_REQUIRED_OR_OPTIONAL "REQUIRED")
set(KDE_FTYPE_REQUIRED_OR_OPTIONAL "REQUIRED")
endif()
2) use that e.g. in knotifications:
find_package(Phonon4Qt5 4.6.60 ${KDE_FIND_REQUIRED_OR_OPTIONAL}
NO_MODULE)
set_package_properties(Phonon4Qt5 PROPERTIES
DESCRIPTION "Qt-based audio library"
TYPE ${KDE_TYPE_REQUIRED_OR_OPTIONAL}
PURPOSE "Required to build audio notification support")
That would at least make people happy that want no missing features and
allow
me and others to work on minimizing the dependencies without annoying
others.
If there is some magic way to set KDE_SKIP_FULL_DEPENDENCIES for
non-distro builds,
that could be added later inside KDECMakeSettings.
I'm not a fan of the variable names - in particular, I think your
original idea for an option name was better than
"KDE_SKIP_FULL_DEPENDENCIES" - the existing KDE_SKIP_* variables are
meant as things project authors define if they only want part of the
module functionality, rather than as something for users/packagers to
set. KDE_FIND_REQUIRED_OR_OPTIONAL also tells me essentially nothing
about *why* it might be REQUIRED or optional when I'm reading the
source.
That said, I'm on board with the overall idea.
Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: phonon hassle to build WAS: Re: Policy for Dependencies
On Wed, Oct 14, 2015 at 9:11 AM, Christoph Cullmann wrote: > Hi, > but why would you want to build a backend if you need no sound anyway? >>> Thats the point, if I don't build a backend, I don't need phonon and I can >>> save building + shipping it with just making phonon optional for >>> knotifications, >>> which internally already is build in a way to have it optional. >> >> So what's the hassle with phonon then? Building? Maybe I am being daft >> today but it seems to me that testing/supporting an entire alternate >> build configuration for knotification is a greater effort than >> building a library that has zero requirements on top of what >> knotification already requires and already does the same thing the >> alternate build configuration would do - i.e. abstract away things you >> might not need. > KNotifications already has that abstraction. > All output things are internal plugins. > And that abstraction is already in use there, for e.g. QtSpeech. > Why build and ship phonon for exactly no gain? > The knotifications change is 5 lines. > If we want to make frameworks attractive for 3rdparty devs, I don't > understand the issue here. Maybe I am thinking of the wrong type of 3rd party dev then. I was under the impression that one shouldn't need to build frameworks themself but rather get a bunch of prebuilt framework bins of which they can choose the ones they need and then build their application on top. Ah well. whatever. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: phonon hassle to build WAS: Re: Policy for Dependencies
Hi, >>> but why would you want to build a backend if you need no sound anyway? >> Thats the point, if I don't build a backend, I don't need phonon and I can >> save building + shipping it with just making phonon optional for >> knotifications, >> which internally already is build in a way to have it optional. > > So what's the hassle with phonon then? Building? Maybe I am being daft > today but it seems to me that testing/supporting an entire alternate > build configuration for knotification is a greater effort than > building a library that has zero requirements on top of what > knotification already requires and already does the same thing the > alternate build configuration would do - i.e. abstract away things you > might not need. KNotifications already has that abstraction. All output things are internal plugins. And that abstraction is already in use there, for e.g. QtSpeech. Why build and ship phonon for exactly no gain? The knotifications change is 5 lines. If we want to make frameworks attractive for 3rdparty devs, I don't understand the issue here. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: phonon hassle to build WAS: Re: Policy for Dependencies
On Wed, Oct 14, 2015 at 8:58 AM, Christoph Cullmann wrote: > Hi, > >> On Wed, Oct 14, 2015 at 8:47 AM, Christoph Cullmann >> wrote: On Tue, Oct 13, 2015 at 8:42 AM, Christoph Cullmann wrote: > phonon is a hassle on both win/mac (if you don't require audio, like most > applications won't) Oo explain please? >>> Hi, >>> >>> to build phonon with an usable backends is work on mac and win >> >> but why would you want to build a backend if you need no sound anyway? > Thats the point, if I don't build a backend, I don't need phonon and I can > save building + shipping it with just making phonon optional for > knotifications, > which internally already is build in a way to have it optional. So what's the hassle with phonon then? Building? Maybe I am being daft today but it seems to me that testing/supporting an entire alternate build configuration for knotification is a greater effort than building a library that has zero requirements on top of what knotification already requires and already does the same thing the alternate build configuration would do - i.e. abstract away things you might not need. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: phonon hassle to build WAS: Re: Policy for Dependencies
Hi, > On Wed, Oct 14, 2015 at 8:47 AM, Christoph Cullmann > wrote: >>> On Tue, Oct 13, 2015 at 8:42 AM, Christoph Cullmann >>> wrote: phonon is a hassle on both win/mac (if you don't require audio, like most applications won't) >>> >>> Oo >>> >>> explain please? >> Hi, >> >> to build phonon with an usable backends is work on mac and win > > but why would you want to build a backend if you need no sound anyway? Thats the point, if I don't build a backend, I don't need phonon and I can save building + shipping it with just making phonon optional for knotifications, which internally already is build in a way to have it optional. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: phonon hassle to build WAS: Re: Policy for Dependencies
On Wed, Oct 14, 2015 at 8:47 AM, Christoph Cullmann wrote: >> On Tue, Oct 13, 2015 at 8:42 AM, Christoph Cullmann >> wrote: >>> phonon is a hassle on both win/mac (if you don't require audio, like most >>> applications won't) >> >> Oo >> >> explain please? > Hi, > > to build phonon with an usable backends is work on mac and win but why would you want to build a backend if you need no sound anyway? ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: phonon hassle to build WAS: Re: Policy for Dependencies
> On Tue, Oct 13, 2015 at 8:42 AM, Christoph Cullmann > wrote: >> phonon is a hassle on both win/mac (if you don't require audio, like most >> applications won't) > > Oo > > explain please? Hi, to build phonon with an usable backends is work on mac and win and e.g. Kate uses no sounds at all normally. That doesn't mean that phonon has any special problems on that architecture, just that it is for many use cases not needed and making it optional in knotifications is 4 lines of code ;=) (beside that it avoids to ship the phonon libs without need in the bundle) I hope I did not offend you ;=) Phonon is for sure buildable there, if you want. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
phonon hassle to build WAS: Re: Policy for Dependencies
On Tue, Oct 13, 2015 at 8:42 AM, Christoph Cullmann wrote: > phonon is a hassle on both win/mac (if you don't require audio, like most > applications won't) Oo explain please? ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Tuesday, October 13, 2015 10:07:18 PM CEST Jaroslaw Staniek wrote: > Hi, > Just wanted to say I'd like to minimize dependencies for Kexi on Windows > too, among other things. > > With my realistic hat on, risky ideas are like: > - depending on kdecoration to just have default icons I hope that's not done anywhere as kdecoration is a kde-workspace library which should only be used by styles and KWin. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hey, On Tue, Oct 13, 2015 at 6:20 PM, Christoph Cullmann wrote: > > I hope I didn't upset anybody, just got a bit frustrated by the current > state of > the art. Alone how many patches for all our stuff are floating around in > the net > to make it somehow buildable instead of some solution inside frameworks > made > me really sad :/ And the amount of work that went into patching Qt to > behave like > on Linux on non-linux makes me even more sad, given the effort of the > people > at the Qt Company to make Qt more native and attractive for these > platforms. > Just for the record, I'm not upset about the KNotification change, I just don't think it's a correct one. That said, I very much support the idea of allowing to build in an essentials-only way. I'm not entirely sure about which approach (per framework or global) is better though. I tend to agree about having per-framework switches and let it up to the integrator to decide what is wanted/needed (in API/ABI limits of course). On the other hand, I can see that going through ~60+ frameworks, reading all the options and setting many of them manually, can be quite tiresome. But as long as specifying such flag is explicit and not on-by-default, I'm happy to look in KNotification framework and see what all can be made non-essential. One other thing that came to my mind, albeit a bit too soon, is the framework's tier. Let's say that in the essentials-only build the tier is actually one or two level above its normal tier; should that be reflected somehow somewhere? Or would tiers just loose their meanings then? Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi, >> > 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. I am all with Albert here, such a global switch that "randomly" deactivates features globally just because e.g. I was to lame to build phonon on some OS is bad. Both the "one global switch to make stuff optional" or "multiple switches to make stuff optional" is a much better route to got that enables people to pick the things they want to have on any OS. Lets see what David thinks about all that. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Albert Astals Cid ha scritto: > El Wednesday 14 October 2015, a les 00:07:10, Jaroslaw Staniek va escriure: >> >> 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. Exactly, it's the same for kdoctools itself. One thing is disable it in each Frameworks to not build the bundled documentation. If you remove it globally, you kill the possibility of having functional help (which is *not* a workspace thing, despite khelpcenter being distributed with Plasma, but it should really be outside). Ciao -- Luigi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
El Wednesday 14 October 2015, a les 00:07:10, Jaroslaw Staniek va escriure: > On 13 October 2015 at 23:22, Albert Astals Cid 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 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi, > El Tuesday 13 October 2015, a les 23:59:33, Christoph Cullmann va escriure: >> Hi, >> >> >> Ok, after the reasonable criticisms of making the sound stuff optional in >> >> knotifications per default: >> >> >> >> Could we have some ECM switch like (name is just an example): >> >> >> >> option(KDE_ENABLE_MINIMAL_DEPENDENCIES "Will switch as many dependencies >> >> from required to optional as possible, this might lead to a loss of >> >> functionality." OFF) >> >> >> >> Based on that option, we can make stuff optional and we will have best of >> >> two worlds: >> >> >> >> 1) no by accident loss of functionality and bug reports (like feared by >> >> some, and I must confess that might be realistic) 2) an easy to use >> >> solution for people wanting minimal dependencies as this is "one" switch >> >> and it will work on all operating systems >> > >> > Why a global one and not one switch per posible optional dependency? >> > >> > cmake -DMAKE_PHONON_OPTIONAL=true >> >> A global switch would make it easy. >> >> You just can switch that one for all your frameworks builds and be done. >> Otherwise, you again need to scan in each framework which thing "can" be >> turned off and which thing is a real hard dependency if the cmake fails. >> >> That doesn't sound very friendly to people trying out our stuff for their >> 3rdparty tools. >> >> With such a global switch, we can advocate: >> >> 1) default cmake config: all things as it should be with all features >> 2) you want minimal dependencies, turn this on and compile, if something is >> still required, it is required, unless you start to patch the stuff >> >> Beside: That will make it easy to implement for me and others, if something >> can be made optional, one can use that globally exported vars to do so >> without inventing for everything yet an other switch. That does not prevent >> that people add additional more fine grained switches to their frameworks, >> as long as the global one still works, IMHO. >> >> Actually I am a bit confused that this is such a controverse thing, btw. >> >> At the moment, the situation is a mess, for all things != Linux. People >> start to fork the stuff and strip it down, people have their >> homebrew/macports/windows patches located everywhere to patch out things. >> >> As Jaroslaw said, ATM it is a bit strange that you need libxml/xslt just to >> build anything non-trivial, because of doctools. I made that already >> optional and I am happy to guard that with the global switch, too, to avoid >> people missing docs by accident on Linux. >> >> I am willing to implement the (rather trivial) extension for ECM and redo >> all my current patches with that thingy and all future ones, too. It will >> fix the issue for != Linux ports and it will still provide the safety >> missed by my premature patch for e.g. knotifications that Martin complained >> about (and yeah, he is right, he/we might get bugreports because of it, >> that is bad). >> >> But I am not really willing to advocate a solution where the default is >> again that one needs to fiddle around with various CMake command line >> arguments just to have the same effect one argument could have just for the >> "fine grained" making stuff optional thingy, which IMHO is not that great, >> we don't disable stuff globally, we just make it optional, you still can >> compile everything like you like, if you provide it. > > Before going any route, please wait for dfaure to come back from his trip, I'm > sure we all agree he's opinion is very valuable on the matter. OK, that is true, David should get a chance to give his opinion, perhaps he has even some better idea how to tackle that problem. I hope I didn't upset anybody, just got a bit frustrated by the current state of the art. Alone how many patches for all our stuff are floating around in the net to make it somehow buildable instead of some solution inside frameworks made me really sad :/ And the amount of work that went into patching Qt to behave like on Linux on non-linux makes me even more sad, given the effort of the people at the Qt Company to make Qt more native and attractive for these platforms. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
El Tuesday 13 October 2015, a les 23:59:33, Christoph Cullmann va escriure: > Hi, > > >> Ok, after the reasonable criticisms of making the sound stuff optional in > >> knotifications per default: > >> > >> Could we have some ECM switch like (name is just an example): > >> > >> option(KDE_ENABLE_MINIMAL_DEPENDENCIES "Will switch as many dependencies > >> from required to optional as possible, this might lead to a loss of > >> functionality." OFF) > >> > >> Based on that option, we can make stuff optional and we will have best of > >> two worlds: > >> > >> 1) no by accident loss of functionality and bug reports (like feared by > >> some, and I must confess that might be realistic) 2) an easy to use > >> solution for people wanting minimal dependencies as this is "one" switch > >> and it will work on all operating systems > > > > Why a global one and not one switch per posible optional dependency? > > > > cmake -DMAKE_PHONON_OPTIONAL=true > > A global switch would make it easy. > > You just can switch that one for all your frameworks builds and be done. > Otherwise, you again need to scan in each framework which thing "can" be > turned off and which thing is a real hard dependency if the cmake fails. > > That doesn't sound very friendly to people trying out our stuff for their > 3rdparty tools. > > With such a global switch, we can advocate: > > 1) default cmake config: all things as it should be with all features > 2) you want minimal dependencies, turn this on and compile, if something is > still required, it is required, unless you start to patch the stuff > > Beside: That will make it easy to implement for me and others, if something > can be made optional, one can use that globally exported vars to do so > without inventing for everything yet an other switch. That does not prevent > that people add additional more fine grained switches to their frameworks, > as long as the global one still works, IMHO. > > Actually I am a bit confused that this is such a controverse thing, btw. > > At the moment, the situation is a mess, for all things != Linux. People > start to fork the stuff and strip it down, people have their > homebrew/macports/windows patches located everywhere to patch out things. > > As Jaroslaw said, ATM it is a bit strange that you need libxml/xslt just to > build anything non-trivial, because of doctools. I made that already > optional and I am happy to guard that with the global switch, too, to avoid > people missing docs by accident on Linux. > > I am willing to implement the (rather trivial) extension for ECM and redo > all my current patches with that thingy and all future ones, too. It will > fix the issue for != Linux ports and it will still provide the safety > missed by my premature patch for e.g. knotifications that Martin complained > about (and yeah, he is right, he/we might get bugreports because of it, > that is bad). > > But I am not really willing to advocate a solution where the default is > again that one needs to fiddle around with various CMake command line > arguments just to have the same effect one argument could have just for the > "fine grained" making stuff optional thingy, which IMHO is not that great, > we don't disable stuff globally, we just make it optional, you still can > compile everything like you like, if you provide it. Before going any route, please wait for dfaure to come back from his trip, I'm sure we all agree he's opinion is very valuable on the matter. Cheers, Albert > > Greetings > Christoph ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On 13 October 2015 at 23:22, Albert Astals Cid 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. 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. 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? -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi, > On 2015-10-13, Martin Graesslin wrote: >> I'm not sure whether it's the best solution. The problem you try to fix with >> it is distros breaking packaging. I agree with Martin K that this is a huge >> problem and that it will happen - since the automation of packages I also >> experienced that nobody looks at the output of optional dependencies and the >> packaging breaks. > > I do think that such packagers should be slapped around with a large > trout. Or something. > >> But I'm not sure how this could be done. Anyway, long story short: I think we >> need the other way around. It should be optional by default, but should be >> turned into stricter requirements on the linux distro case. > > There is also another angle to the dependencies. What dependencies can > be enabled/disabled without requiring changes to users of the library. > > Or put it another way. Is the enabling/disabling of a given feature ABI > and API compatible. > > I do think that for features that doesn't impact the API/ABI we should > make it very easy to enable/disable them. Like based on having things > present on the system or not. > > But for things that affects the API/ABI of the library, people should be > explicit about it. At the moment I am only talking about dependencies that would not change the API/ABI but just remove some internal parts to be build or tools to be shipped. I agree, that if the API/ABI is modified, it should be made explicit, to not introduce incompatibilties too easily. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi, >> Ok, after the reasonable criticisms of making the sound stuff optional in >> knotifications per default: >> >> Could we have some ECM switch like (name is just an example): >> >> option(KDE_ENABLE_MINIMAL_DEPENDENCIES "Will switch as many dependencies >> from required to optional as possible, this might lead to a loss of >> functionality." OFF) >> >> Based on that option, we can make stuff optional and we will have best of >> two worlds: >> >> 1) no by accident loss of functionality and bug reports (like feared by >> some, and I must confess that might be realistic) 2) an easy to use >> solution for people wanting minimal dependencies as this is "one" switch >> and it will work on all operating systems > > Why a global one and not one switch per posible optional dependency? > > cmake -DMAKE_PHONON_OPTIONAL=true A global switch would make it easy. You just can switch that one for all your frameworks builds and be done. Otherwise, you again need to scan in each framework which thing "can" be turned off and which thing is a real hard dependency if the cmake fails. That doesn't sound very friendly to people trying out our stuff for their 3rdparty tools. With such a global switch, we can advocate: 1) default cmake config: all things as it should be with all features 2) you want minimal dependencies, turn this on and compile, if something is still required, it is required, unless you start to patch the stuff Beside: That will make it easy to implement for me and others, if something can be made optional, one can use that globally exported vars to do so without inventing for everything yet an other switch. That does not prevent that people add additional more fine grained switches to their frameworks, as long as the global one still works, IMHO. Actually I am a bit confused that this is such a controverse thing, btw. At the moment, the situation is a mess, for all things != Linux. People start to fork the stuff and strip it down, people have their homebrew/macports/windows patches located everywhere to patch out things. As Jaroslaw said, ATM it is a bit strange that you need libxml/xslt just to build anything non-trivial, because of doctools. I made that already optional and I am happy to guard that with the global switch, too, to avoid people missing docs by accident on Linux. I am willing to implement the (rather trivial) extension for ECM and redo all my current patches with that thingy and all future ones, too. It will fix the issue for != Linux ports and it will still provide the safety missed by my premature patch for e.g. knotifications that Martin complained about (and yeah, he is right, he/we might get bugreports because of it, that is bad). But I am not really willing to advocate a solution where the default is again that one needs to fiddle around with various CMake command line arguments just to have the same effect one argument could have just for the "fine grained" making stuff optional thingy, which IMHO is not that great, we don't disable stuff globally, we just make it optional, you still can compile everything like you like, if you provide it. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
El Tuesday 13 October 2015, a les 14:20:31, Christoph Cullmann va escriure: > Hi, > > different take on that below: > > Hi, > > > >> 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 ... > > > > For X11 that might cut it, as it is non-sense to compile it on mac, but I > > doubt such > > global magic will cut it for other stuff like phonon or dbus. > > > > You might want to have both on mac and windows, too. > > > > If we start to make this global disabled, we will annoy people, too. > > In addition: If we want to have 3rdparty devs use our stuff, it must be > > possible to avoid these dependencies on Linux, too. > > > > I really would like to have the normal CMake strategy: non-required stuff > > is optional. > > > > For KNotifications thats even obvious, given its internals are build in a > > ways that this > > stuff is an internal "plugin". > > > > I don't think we need yet an other level of magic, beside things like "X11 > > on Mac/Win are non-brainers", > > which is not much more than we do with other global compiler/cmake flags > > specific for OSes. > > Ok, after the reasonable criticisms of making the sound stuff optional in > knotifications per default: > > Could we have some ECM switch like (name is just an example): > > option(KDE_ENABLE_MINIMAL_DEPENDENCIES "Will switch as many dependencies > from required to optional as possible, this might lead to a loss of > functionality." OFF) > > Based on that option, we can make stuff optional and we will have best of > two worlds: > > 1) no by accident loss of functionality and bug reports (like feared by > some, and I must confess that might be realistic) 2) an easy to use > solution for people wanting minimal dependencies as this is "one" switch > and it will work on all operating systems Why a global one and not one switch per posible optional dependency? cmake -DMAKE_PHONON_OPTIONAL=true Cheers, Albert > > Greetings > Christoph ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
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. Cheers, Albert > > Cheers > Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi,
Just wanted to say I'd like to minimize dependencies for Kexi on Windows
too, among other things.
With my realistic hat on, risky ideas are like:
- depending on kdecoration to just have default icons
- build-time depending on xml/docbook processing tools to just have core
KF5 libs built
- 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)
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.
Christoph mentioned the example with sound, which sincely belongs to this
group too.
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...
On 13 October 2015 at 17:54, Christoph Cullmann wrote:
> Hi,
>
> >> I'm not sure whether it's the best solution. The problem you try to fix
> with
> >> it is distros breaking packaging. I agree with Martin K that this is a
> huge
> >> problem and that it will happen - since the automation of packages I
> also
> >> experienced that nobody looks at the output of optional dependencies
> and the
> >> packaging breaks.
> >>
> >> Given that I don't think we want an ENABLE_MINIMAL_DEPENDENCIES switch,
> but
> >> rather a mode which will break if not found during distro builds.
> >>
> >> Something like a "STRONGLY_RECOMMENDED" which is turned into "REQUIRED"
> if
> >> distros build (and maybe also kdesrc-build), but is optional if anybody
> else
> >> builds.
> >>
> >> But I'm not sure how this could be done. Anyway, long story short: I
> think we
> >> need the other way around. It should be optional by default, but should
> be
> >> turned into stricter requirements on the linux distro case.
> > I would be happy with such an solution, too.
> > But I am not that optimistic that this is easy to achieve, how to ensure
> all
> > distros
> > turn this magic on?
> >
> > The opposite direction at least would avoid the distro breakage and
> still allow
> > optional compiles for the "3rd party wants less dependencies" or "other
> platform
> > wants
> > less dependencies" use case.
> >
> > Even if not optimal, some ENABLE_MINIMAL_DEPENDENCIES would in my eyes
> still
> > better than
> > the current situation, were either we have optional stuff that will make
> us
> > unhappy because
> > of broken distro packages or the devs unhappy that need to patch
> dependencies
> > out on their own.
> >
> > e.g. Kåre did in most cases exactly that for the Windows build
> > (g...@git.kde.org:scratch/sars/kate-windows),
> > which IMHO is sad.
>
> My ECM proposal would be the following:
>
> 1) add to KDECMakeSettings.cmake:
>
> Dependencies mode
>
> if(KDE_SKIP_FULL_DEPENDENCIES)
> unset(KDE_FIND_REQUIRED_OR_OPTIONAL)
> set(KDE_TYPE_REQUIRED_OR_OPTIONAL "OPTIONAL")
> else()
> set(KDE_FIND_REQUIRED_OR_OPTIONAL "REQUIRED")
> set(KDE_FTYPE_REQUIRED_OR_OPTIONAL "REQUIRED")
> endif()
>
> 2) use that e.g. in knotifications:
>
> find_package(Phonon4Qt5 4.6.60 ${KDE_FIND_REQUIRED_OR_OPTIONAL} NO_MODULE)
> set_package_properties(Phonon4Qt5 PROPERTIES
>DESCRIPTION "Qt-based audio library"
>TYPE ${KDE_TYPE_REQUIRED_OR_OPTIONAL}
>PURPOSE "Required to build audio notification support")
>
> That would at least make people happy that want no missing features and
> allow
> me and others to work on minimizing the dependencies without annoying
> others.
>
> If there is some magic way to set KDE_SKIP_FULL_DEPENDENCIES for
> non-distro builds,
> that could be added later inside KDECMakeSettings.
>
> Greetings
> Christoph
>
> --
> - Dr.-Ing. Christoph Cullmann -
> AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com
> Science Park 1 Tel: +49-681-38360-22
> 66123 Saarbrücken Fax: +49-681-38360-20
> GERMANYWWW: http://www.AbsInt.com
>
> Geschäftsführung: Dr.-Ing. Christian Ferdinand
> Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development
Re: Policy for Dependencies
On 2015-10-13, Martin Graesslin wrote: > I'm not sure whether it's the best solution. The problem you try to fix with > it is distros breaking packaging. I agree with Martin K that this is a huge > problem and that it will happen - since the automation of packages I also > experienced that nobody looks at the output of optional dependencies and the > packaging breaks. I do think that such packagers should be slapped around with a large trout. Or something. > But I'm not sure how this could be done. Anyway, long story short: I think we > need the other way around. It should be optional by default, but should be > turned into stricter requirements on the linux distro case. There is also another angle to the dependencies. What dependencies can be enabled/disabled without requiring changes to users of the library. Or put it another way. Is the enabling/disabling of a given feature ABI and API compatible. I do think that for features that doesn't impact the API/ABI we should make it very easy to enable/disable them. Like based on having things present on the system or not. But for things that affects the API/ABI of the library, people should be explicit about it. /Sune ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi,
>> I'm not sure whether it's the best solution. The problem you try to fix with
>> it is distros breaking packaging. I agree with Martin K that this is a huge
>> problem and that it will happen - since the automation of packages I also
>> experienced that nobody looks at the output of optional dependencies and the
>> packaging breaks.
>>
>> Given that I don't think we want an ENABLE_MINIMAL_DEPENDENCIES switch, but
>> rather a mode which will break if not found during distro builds.
>>
>> Something like a "STRONGLY_RECOMMENDED" which is turned into "REQUIRED" if
>> distros build (and maybe also kdesrc-build), but is optional if anybody else
>> builds.
>>
>> But I'm not sure how this could be done. Anyway, long story short: I think we
>> need the other way around. It should be optional by default, but should be
>> turned into stricter requirements on the linux distro case.
> I would be happy with such an solution, too.
> But I am not that optimistic that this is easy to achieve, how to ensure all
> distros
> turn this magic on?
>
> The opposite direction at least would avoid the distro breakage and still
> allow
> optional compiles for the "3rd party wants less dependencies" or "other
> platform
> wants
> less dependencies" use case.
>
> Even if not optimal, some ENABLE_MINIMAL_DEPENDENCIES would in my eyes still
> better than
> the current situation, were either we have optional stuff that will make us
> unhappy because
> of broken distro packages or the devs unhappy that need to patch dependencies
> out on their own.
>
> e.g. Kåre did in most cases exactly that for the Windows build
> (g...@git.kde.org:scratch/sars/kate-windows),
> which IMHO is sad.
My ECM proposal would be the following:
1) add to KDECMakeSettings.cmake:
Dependencies mode
if(KDE_SKIP_FULL_DEPENDENCIES)
unset(KDE_FIND_REQUIRED_OR_OPTIONAL)
set(KDE_TYPE_REQUIRED_OR_OPTIONAL "OPTIONAL")
else()
set(KDE_FIND_REQUIRED_OR_OPTIONAL "REQUIRED")
set(KDE_FTYPE_REQUIRED_OR_OPTIONAL "REQUIRED")
endif()
2) use that e.g. in knotifications:
find_package(Phonon4Qt5 4.6.60 ${KDE_FIND_REQUIRED_OR_OPTIONAL} NO_MODULE)
set_package_properties(Phonon4Qt5 PROPERTIES
DESCRIPTION "Qt-based audio library"
TYPE ${KDE_TYPE_REQUIRED_OR_OPTIONAL}
PURPOSE "Required to build audio notification support")
That would at least make people happy that want no missing features and allow
me and others to work on minimizing the dependencies without annoying others.
If there is some magic way to set KDE_SKIP_FULL_DEPENDENCIES for non-distro
builds,
that could be added later inside KDECMakeSettings.
Greetings
Christoph
--
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com
Science Park 1 Tel: +49-681-38360-22
66123 Saarbrücken Fax: +49-681-38360-20
GERMANYWWW: http://www.AbsInt.com
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi, >> Ok, after the reasonable criticisms of making the sound stuff optional in >> knotifications per default: >> >> Could we have some ECM switch like (name is just an example): >> >> option(KDE_ENABLE_MINIMAL_DEPENDENCIES "Will switch as many dependencies >> from required to optional as possible, this might lead to a loss of >> functionality." OFF) >> >> Based on that option, we can make stuff optional and we will have best of >> two worlds: >> >> 1) no by accident loss of functionality and bug reports (like feared by >> some, and I must confess that might be realistic) 2) an easy to use >> solution for people wanting minimal dependencies as this is "one" switch >> and it will work on all operating systems > > I'm not sure whether it's the best solution. The problem you try to fix with > it is distros breaking packaging. I agree with Martin K that this is a huge > problem and that it will happen - since the automation of packages I also > experienced that nobody looks at the output of optional dependencies and the > packaging breaks. > > Given that I don't think we want an ENABLE_MINIMAL_DEPENDENCIES switch, but > rather a mode which will break if not found during distro builds. > > Something like a "STRONGLY_RECOMMENDED" which is turned into "REQUIRED" if > distros build (and maybe also kdesrc-build), but is optional if anybody else > builds. > > But I'm not sure how this could be done. Anyway, long story short: I think we > need the other way around. It should be optional by default, but should be > turned into stricter requirements on the linux distro case. I would be happy with such an solution, too. But I am not that optimistic that this is easy to achieve, how to ensure all distros turn this magic on? The opposite direction at least would avoid the distro breakage and still allow optional compiles for the "3rd party wants less dependencies" or "other platform wants less dependencies" use case. Even if not optimal, some ENABLE_MINIMAL_DEPENDENCIES would in my eyes still better than the current situation, were either we have optional stuff that will make us unhappy because of broken distro packages or the devs unhappy that need to patch dependencies out on their own. e.g. Kåre did in most cases exactly that for the Windows build (g...@git.kde.org:scratch/sars/kate-windows), which IMHO is sad. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Tuesday, October 13, 2015 2:20:31 PM CEST Christoph Cullmann wrote: > Hi, > > different take on that below: > > Hi, > > > >> 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 ... > > > > For X11 that might cut it, as it is non-sense to compile it on mac, but I > > doubt such > > global magic will cut it for other stuff like phonon or dbus. > > > > You might want to have both on mac and windows, too. > > > > If we start to make this global disabled, we will annoy people, too. > > In addition: If we want to have 3rdparty devs use our stuff, it must be > > possible to avoid these dependencies on Linux, too. > > > > I really would like to have the normal CMake strategy: non-required stuff > > is optional. > > > > For KNotifications thats even obvious, given its internals are build in a > > ways that this > > stuff is an internal "plugin". > > > > I don't think we need yet an other level of magic, beside things like "X11 > > on Mac/Win are non-brainers", > > which is not much more than we do with other global compiler/cmake flags > > specific for OSes. > > Ok, after the reasonable criticisms of making the sound stuff optional in > knotifications per default: > > Could we have some ECM switch like (name is just an example): > > option(KDE_ENABLE_MINIMAL_DEPENDENCIES "Will switch as many dependencies > from required to optional as possible, this might lead to a loss of > functionality." OFF) > > Based on that option, we can make stuff optional and we will have best of > two worlds: > > 1) no by accident loss of functionality and bug reports (like feared by > some, and I must confess that might be realistic) 2) an easy to use > solution for people wanting minimal dependencies as this is "one" switch > and it will work on all operating systems I'm not sure whether it's the best solution. The problem you try to fix with it is distros breaking packaging. I agree with Martin K that this is a huge problem and that it will happen - since the automation of packages I also experienced that nobody looks at the output of optional dependencies and the packaging breaks. Given that I don't think we want an ENABLE_MINIMAL_DEPENDENCIES switch, but rather a mode which will break if not found during distro builds. Something like a "STRONGLY_RECOMMENDED" which is turned into "REQUIRED" if distros build (and maybe also kdesrc-build), but is optional if anybody else builds. But I'm not sure how this could be done. Anyway, long story short: I think we need the other way around. It should be optional by default, but should be turned into stricter requirements on the linux distro case. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi, >> Ok, after the reasonable criticisms of making the sound stuff optional in >> knotifications per default: >> >> Could we have some ECM switch like (name is just an example): >> >> option(KDE_ENABLE_MINIMAL_DEPENDENCIES "Will switch as many dependencies from >> required to optional as possible, this might lead to a loss of >> functionality." >> OFF) >> >> Based on that option, we can make stuff optional and we will have best of two >> worlds: >> >> 1) no by accident loss of functionality and bug reports (like feared by some, >> and I must confess that might be realistic) >> 2) an easy to use solution for people wanting minimal dependencies as this is >> "one" switch and it will work on all operating systems > > I think we're mixing different subjects here. One thing is being able > to be as portable as possible and another thing is to have few > dependencies. Dependencies are a portability problem as they make the > process a bit more complex, but also this process needs to be > standardized. The reason why dependencies are a problem when we port, > is because these pop when we as humble developers try to play the > packager role, and we're not used it it. > > My proposal is that we should make sure which frameworks are viable on > each platform. If a framework is not viable on a platform (be it > because it's not an abstraction or because it doesn't make sense) then > other frameworks must either inherit the non-viability or make the > framework usage optional. And so should do applications that aspire to > be portable, which is by no means required. > > I'm not sure though how acceptable is to drop functionality in favor > of just reducing the dependency list. I don't really think that this is mixing things. I think we must accept, that on neither Windows nor Mac we will have all dependencies available and that for many applications not all features are needed. There is no "packagers" for that operating systems, you need to provide the stuff you use yourself, just like you would do on Android/iOS. E.g. no, I doubt that Krita or Kate will suffer a lot, if we have no sound, nor will many 3rdparty applications. We can make the knotifications usage more optional, e.g. in kparts, or we can make the knotifications dependencies more optional. Therefore I think less dependencies are needed to be called "portable" in that case. But that a side, for the dependencies itself, no matter if we target just one os or multiple, would the KDE_ENABLE_MINIMAL_DEPENDENCIES switch be a solution for the criticism raised? It at least would provide some generic and "opt-in" way for people compiling our stuff to say "I want to have minimal dependencies and are aware of loss of functionality if stuff is missing" opposed to my/our current approach to make things optional per default. With that variable available, I could e.g. make even libgit2 required for KTextEditor to ensure per default I have good git integration and make it optional with that var to still allow people to build it if the really want to loose that. Same for Kate with its plugins. Would save me bug reports about missing things, too. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
On Tue, Oct 13, 2015 at 2:20 PM, Christoph Cullmann wrote: > Hi, > > different take on that below: > >> Hi, >> >>> 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 ... >> >> For X11 that might cut it, as it is non-sense to compile it on mac, but I >> doubt >> such >> global magic will cut it for other stuff like phonon or dbus. >> >> You might want to have both on mac and windows, too. >> >> If we start to make this global disabled, we will annoy people, too. >> In addition: If we want to have 3rdparty devs use our stuff, it must be >> possible >> to avoid these dependencies on Linux, too. >> >> I really would like to have the normal CMake strategy: non-required stuff is >> optional. >> >> For KNotifications thats even obvious, given its internals are build in a >> ways >> that this >> stuff is an internal "plugin". >> >> I don't think we need yet an other level of magic, beside things like "X11 on >> Mac/Win are non-brainers", >> which is not much more than we do with other global compiler/cmake flags >> specific for OSes. > > Ok, after the reasonable criticisms of making the sound stuff optional in > knotifications per default: > > Could we have some ECM switch like (name is just an example): > > option(KDE_ENABLE_MINIMAL_DEPENDENCIES "Will switch as many dependencies from > required to optional as possible, this might lead to a loss of > functionality." OFF) > > Based on that option, we can make stuff optional and we will have best of two > worlds: > > 1) no by accident loss of functionality and bug reports (like feared by some, > and I must confess that might be realistic) > 2) an easy to use solution for people wanting minimal dependencies as this is > "one" switch and it will work on all operating systems I think we're mixing different subjects here. One thing is being able to be as portable as possible and another thing is to have few dependencies. Dependencies are a portability problem as they make the process a bit more complex, but also this process needs to be standardized. The reason why dependencies are a problem when we port, is because these pop when we as humble developers try to play the packager role, and we're not used it it. My proposal is that we should make sure which frameworks are viable on each platform. If a framework is not viable on a platform (be it because it's not an abstraction or because it doesn't make sense) then other frameworks must either inherit the non-viability or make the framework usage optional. And so should do applications that aspire to be portable, which is by no means required. I'm not sure though how acceptable is to drop functionality in favor of just reducing the dependency list. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi, different take on that below: > Hi, > >> 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 ... > > For X11 that might cut it, as it is non-sense to compile it on mac, but I > doubt > such > global magic will cut it for other stuff like phonon or dbus. > > You might want to have both on mac and windows, too. > > If we start to make this global disabled, we will annoy people, too. > In addition: If we want to have 3rdparty devs use our stuff, it must be > possible > to avoid these dependencies on Linux, too. > > I really would like to have the normal CMake strategy: non-required stuff is > optional. > > For KNotifications thats even obvious, given its internals are build in a ways > that this > stuff is an internal "plugin". > > I don't think we need yet an other level of magic, beside things like "X11 on > Mac/Win are non-brainers", > which is not much more than we do with other global compiler/cmake flags > specific for OSes. Ok, after the reasonable criticisms of making the sound stuff optional in knotifications per default: Could we have some ECM switch like (name is just an example): option(KDE_ENABLE_MINIMAL_DEPENDENCIES "Will switch as many dependencies from required to optional as possible, this might lead to a loss of functionality." OFF) Based on that option, we can make stuff optional and we will have best of two worlds: 1) no by accident loss of functionality and bug reports (like feared by some, and I must confess that might be realistic) 2) an easy to use solution for people wanting minimal dependencies as this is "one" switch and it will work on all operating systems Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
Hi, > 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 ... For X11 that might cut it, as it is non-sense to compile it on mac, but I doubt such global magic will cut it for other stuff like phonon or dbus. You might want to have both on mac and windows, too. If we start to make this global disabled, we will annoy people, too. In addition: If we want to have 3rdparty devs use our stuff, it must be possible to avoid these dependencies on Linux, too. I really would like to have the normal CMake strategy: non-required stuff is optional. For KNotifications thats even obvious, given its internals are build in a ways that this stuff is an internal "plugin". I don't think we need yet an other level of magic, beside things like "X11 on Mac/Win are non-brainers", which is not much more than we do with other global compiler/cmake flags specific for OSes. Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Policy for Dependencies
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 ... Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
