Policy for Dependencies

[Jeremy Whiting]

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 <boud at valdyas.org> 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 at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel