Re: [reposted from kde-devel] Building KDE statically

2019-03-02 Thread Volker Krause
On Saturday, 2 March 2019 00:23:38 CET Jonathan Schultz wrote:
> If anyone is interested, here is a brief report on something I have been
> working on in my spare time.
> 
> TLDR: Here are some scripts to build KDE frameworks and okular statically
> using gcc/musl and cross-building for mingw:
> https://github.com/jschultz/kde-static Look in the file patch-kde.sh to see
> the interesting stuff.

Interesting, thanks for sharing this! Static builds are also interesting for 
deployment by application bundles (such as APKs on Android), so I'd very much 
like to see the necessary changes to go upstream eventually :)

[...]
> Most of the patches are simply to make CMake handle static dependencies. A
> few deal with ad hoc issues that arose out of static building. The most
> complicated was linking okular's plugins statically, which involved a bit
> of build hacking, but nothing too dreadful (IMHO).

Regarding the transitive dependency issue, I think the cleaner and easier to 
use way is to not add them conditionally to each consuming module, but let the 
CMake config files of the module bringing in that transitive dependency search 
for them. Ie. like https://phabricator.kde.org/
R174:085ac943d0c00dd1d88650ab27c737b709870d9b, but possibly conditional for 
static builds.

[...]
> I also put in some cross-building stuff. Since kdesrc-build seems not to do
> a good job with host applications required for the building process, I just
> pre-built those and put the executables in the repository. Not all of
> frameworks cross-builds, but enough to link okular does.

Most of them should cross-build, but not all of them follow the canonical 
approach with KF5_HOST_TOOLING yet. The Yocto recipes for KF5 (https://
phabricator.kde.org/source/yocto-meta-kf5/browse/master/recipes-kf5/) might 
contain useful hints on how to cross-compile a given framework.

Regards,
Volker

signature.asc
Description: This is a digitally signed message part.


[reposted from kde-devel] Building KDE statically

2019-03-01 Thread Jonathan Schultz

Hello KDE developers,

If anyone is interested, here is a brief report on something I have been 
working on in my spare time.

TLDR: Here are some scripts to build KDE frameworks and okular statically using 
gcc/musl and cross-building for mingw: https://github.com/jschultz/kde-static 
Look in the file patch-kde.sh to see the interesting stuff.

I've been working on an application based largely on okular that I would like 
to be able to deploy as simply as possible for users with no technical 
expertise. For this purpose, and despite its well-known down-sides I thought 
that a static build would be helpful.

So I started building KDE frameworks and other okular dependencies using 
kdesrc-build and working out what would need to change to make a static build. 
It turned out to be more painstaking but less complicated than I had imagined.

It all happens inside Docker containers built on voidlinux, which I chose 
because it handles musl natively and has a build process simple enough for me 
to understand. No doubt there are good reasons to use a different Linux distro 
but so be it.

Most of the patches are simply to make CMake handle static dependencies. A few 
deal with ad hoc issues that arose out of static building. The most complicated 
was linking okular's plugins statically, which involved a bit of build hacking, 
but nothing too dreadful (IMHO).

I've made all the patches backwards-compatible, ie they have no effect on a 
conventional build using shared libraries.

I took some shortcuts in working out which static libraries to include, ie 
basically all libraries are included on all link operations, and we count on 
the linker to leave out those that aren't required.

I also put in some cross-building stuff. Since kdesrc-build seems not to do a 
good job with host applications required for the building process, I just 
pre-built those and put the executables in the repository. Not all of 
frameworks cross-builds, but enough to link okular does.

What it produces:

An static okular executable with the following generator plugins: poppler, 
kimgio, dvi, tiff, xps, ooo, fb, comicbook, fax, plucker, txt is about 88MB in 
size. I understand that this might be reduced, possibly by as much as 80%, by 
using Link-Time Optimisation (LTO). Even as it is, it starts and runs 
noticeably faster than a conventional build. Cross-building, a mingw32 
okular.exe is around 58MB and a mingw64 73MB.

Still some problems: it can't save files because (if I understand correctly) 
kio uses slave processes that are also based on plugins which would need to be 
linked statically.

What's next: Cross-building for MacOS. Using craft instead of kdesrc-build.

So feel free to hit me up with suggestions, interest or if anyone is interested 
in incorporating any of this into the mainline of KDE development.

Cheers,
Jonathan