Policy for Dependencies

[Boudewijn Rempt]

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.