[KDE/Mac] Re: CMake to deploy package for Mac (Re: Developing KDE on Mac)

[Mike McQuaid]

On 30 Sep 2010, at 19:51, Bernhard Reiter wrote:

> In light of not having used CPack at all, I like to know to understand more 
> about the solution proposed by you.
> 
> How does this solve the issues of:
> * Running an stopping various processes (like dbus) that should be unique?

CPack doesn't solve this issue, you need to solve it yourself. D-Bus could be either installed a system dependency (perhaps with KDELibs) or we can just run a local D-Bus instance if it is needed on application creation.

> * Packaging up the exact and complete source code for your binaries
>  (of course excluding system libraries, but including external ones)?

CPack provides a make source_package feature which allows you to package the source code of your project. You could also add external libraries, if you felt the need. I don't think we need to package e.g. Qt if we're using unmodified sources.

> * The rebuilding of the complete source code, once I have it?

That's the advantage of the CPack solution. If done properly, all it should require is "make package" to build the software and a redistributable package. I don't think we need to build Qt. I'm not aware of any other KDE distribution that supplies all source dependencies in one location.

> * Updates of a part of the dependencies do require a complete and full
>  rebuild? (Because we cannot be sure that rebuilding works until it has
>  been done successfully first and no intermediate step can reconstructed
>  reliably.)

You would create a new package if you wanted to use a new version of Qt.

>> The .dmg is 6.4MB and the installed .app is 20MB. This
>> somewhat destroys your claim that "bundling a Qt framework inside the .app
>> makes the .app grow by a few hundred MB".
> 
> Potentially there are hundreds of interesting Free Software applications
> for Mac, at some point being able to use shared resource will have an
> significant effect.



On Windows, do you install Qt into C:\Windows\System32? If not, why not?

With respect, people who insist on sharing libraries like this don't the way software is usually distributed on Mac or Windows. The reason you don't share libraries is because the hard disk requirements are small enough to be inconsequential. With the above example, if you're talking about maybe 15MB of Qt libraries per application (I'm sure I could optimise that further) when the average size of hard disk on new machines is 500GB. It really doesn't matter if they are duplicated 10 times.

Fundamentally, Apple don't recommend deploying applications like that. The users don't want to worry about installing and uninstalling applications in some new way so the libraries are shared. The developers' lives are made much easier when they only need to support a single version of Qt, D-Bus and KDELibs rather than this being updated when the user installs a new piece of software.

I know this is free software but looking at the way Linux does things and trying to apply it to Mac and Windows is the wrong way round. If you want to produce software that your users will want to use, you want to do things in the way they expect it to behave on that platform. This much is basic HCI and it's why Qt spends so much time trying to do the most sensible native behaviour on each platform.

If we make it much harder to install Kontact than Thunderbird (which pretty much every proposal other than the CPack one does) then users will not use Kontact. This is why I don't use Kontact as my mail client at the moment and why many of the KDE on Mac people don't do so either: because it's a significant burden on the users to attempt to use it in Macports/Fink compared to native clients.

--
Cheers,
Mike McQuaid
http://mikemcquaid.com