libavif.a should not be a combined archive library about libavif

[fdintino]

I believe it only combines the archives for dependencies that are built locally. A system static library is in principle portable, whereas ext/SVT-AV1/Bin/Release/libSvtAv1Enc.a is not. If this is not the desired behavior, I don't think it would be terribly difficult to put it behind some sort of FULL_STATIC_BUILD cmake option. Should I open a pull request to that effect?

[wantehchang]

Frankie: Thanks for the quick reply. I think it is best if libavif.a always has the standard meaning that people expect, containing only libavif itself. We can add a cmake option to produce an additional static library, say libavif_combined.a, that also includes the archives for dependencies.

I have a question about your comment. You said "A system static library is in principle portable". By "portable", did you mean position-independent code?

[fdintino]

I mean that you could distribute libavif.a and reasonably expect other users to be able to link against it. In an rpm/deb/apk for instance, where ABI compatibility can be enforced. (edit: pkg-config could also serve this purpose, if we had dependencies in the .pc file)

[fdintino]

If someone wanted to distribute a library for node or python that had libavif bindings, it would be convenient to be able to take advantage of the local dependency builds, but if those dependencies weren't combined in the archive then when you went to link libavif.a you'd also need to track down all of the static files for those dependencies, wherever they might have ended up as interim build products.

[fdintino]

What if it only libraries that were compiled in the build directory (in other words, not in the ext directory) are merged into libavif.a? That would ensure that any projects that depend on the past behavior and locations of the static libraries in the ext folder would continue to work. Whereas the directory structure for intermediate externalproject and fetchcontent artifacts inside the build directory is meant to be opaque. It's not reasonable to expect a user to hunt the static lib files down so that they can link against libavif.a.