How to build for Windows as static libraries?

[dgnuff]

The main .md file for libheif recommends using vcpkg to install and build libheif for Windows. The issue for me is that this produces dlls that need to be distributed with my application.

I would much rather generate static libraries that are directly linked into the application, thus letting me keep it down to a single executable.

Since I have zero - none - nada experience with cmake, I don't even know where to begin. It appears that files with the name CMakeLists.txt are the cmake equivalent of Makefiles, but I have no idea which of these I need to change, what modifications I need to make to them, and how to execute cmake to build when I'm finished.

Looking for someone to walk me through the process of building libheif, libde265 and x265 as static link .LIB files.

[farindk]

Note that static linking is not allowed by the LGPL license.
When you distribute your software as a binary, you have to link dynamically to libheif.

And by the way: x265 is GPL. You may only use that in your software if you also release the source code of your software.

[dgnuff]

Firstly, x265 (and hence GPL) can be ignored here because the application will only use libheif and libde265, both of which are LGPL.

That said, LGPL does not prohibit static linkage.

On the contrary, Section 4.d.0 allows distribution of a covered "Combined Work", which is what this would be. The conditions are that I would also make available the "Minimal Corresponding Source", which would be the source file(s) from my application that directly interface with libheif, and the rest of the application in "a form suitable for, ..., the user to recombine or relink the Application ...".

Granted, Section 4.d.1 which covers works that use dynamically linked libraries does not require any such source / object distribution, making the release process much easier, but as outlined above, it is not the only way to satisfy the requirements of the LGPL.

But here's the key point. The application in question will never be distributed to the public, it is for my own personal use only. Therefore any terms of the LGPL regarding distribution are a complete non-issue in my case.

[silverbacknet]

libheif is going to be a bit of a slog to cut your teeth on, but since you have to start with libde265 anyway, it won't be too bad.

The basic cmake gui is functional enough, point it to the base folder and then pick a build folder anywhere you want, hit configure, pick your build environment. You can choose options there, all you want is to uncheck BUILD_SHARED_LIBS, generate, open project or go find the project files in your build folder, and build.

So opening libheif and changing to a new build folder for that (the UI is clunky about changing projects), configure. Uncheck the same BUILD_SHARED_LIBS, and skip down to LIBDE265_INCLUDE_DIR and LIBDE265_LIBRARY, fill them in appropriately. Uncheck everything in the list of plugins except WITH_LIBDE265. Maybe uncheck ENABLE_PLUGIN_LOADING. Now generate. That should get you a set of project files that will build you a minimally functional set of self-contained libheif executables. Rinse and repeat for JPEG/PNG/OpenJPG libraries if you want to be able to output into a useful format.

BUILD_TESTING will generate a LOT of project files, that might be one you want to disable as well.

Once you get the hang of it, you can do it all via commandline like a regular makefile process. The gui has Tools->Show My Changes that will give you the full commandline. But that's a tall order when you're not sure how cmake works at all yet.

Edit: Of all the libraries, AOM is by far the biggest pain in the ass to build, but you'll really get the hang of cmake with that.

[dgnuff]

@silverbacknet It turns out it was remarkably easy, once I pointed cmake-gui at the problem.

I also decided to do the smart thing and have my project use libde265 and libheif as submodules.

TL;DR go through the steps with cmake-gui, making the changes you recommended, and then have it generate projects, working with the submodules within my main project. That caused it to produce a number of Visual Studio .vcxproj files. It was then completely trivial to copy those generated project files from the build folder, to my main app's project folder, fiddle with them a little to clean things up and make them play nicely with the main project, and I've got it generating static libraries for everything.

A minor curiosity is that each subproject of libde265 and libheif now produces its own output library, rather than the two monolithic libraries I was getting via cmake. That means that the final linker stage of the main project requires a few more input files, but it has a huge advantage as far as speed is concerned.

With cmake, (e.g.) libde265 had to build all the subprojects first and only then could it build the final library, resulting in an effective two-step process just to get that library. With my setup, build goes somewhat faster because all the library projects can be built in parallel: libde265, libheif, the whole enchilada.