add a pkg-config file

[selfisekai]

makes reuse as shared library easier. example generated file:

prefix="/usr/local"
exec_prefix="${prefix}"
libdir="${prefix}/lib"
includedir="${prefix}/include"

Name: base64
Description: Fast Base64 stream encoder/decoder in C99, with SIMD acceleration
Version: 0.5.1
Cflags: -I${includedir}
Libs: -L${libdir} -lbase64

[selfisekai]

to my knowledge, it does not (it's gn). electron creates their buildscripts manually https://github.com/electron/electron/blob/95d094d75bddb99c83d2902fbc9a4335632a41cf/patches/node/build_add_gn_build_files.patch#L450

[selfisekai]

is this correct?

[aklomp]

@BurningEnlightenment Does this look good to you after the fixes? I don't really have enough knowledge about pkg-config configs to come to a conclusion.

In cases like this I'm usually in favour of merging it so it gets traction. Then we can see how the cards shake out (i.e. who starts complaining).

[selfisekai]

not sure how would that work since the same pkg-config files are used whether you add --static or not. i don't see a reason why building with both BUILD_SHARED_LIBS=ON and BUILD_STATIC_LIBS=ON wouldn't be allowed if you want both, and some of our packages do just that (e.g. https://gitlab.alpinelinux.org/alpine/aports/-/blob/f3273b0dc7964024f698aa376736975db0b4ef3c/main/snappy/APKBUILD#L36-37)

Wasn't it recommended practice for gn to provide custom buildfiles for 3rdparty dependencies?

ime that's what gn projects typically do for themselves, as they typically compile everything statically, but when they sometimes don't, they typically go with pkg-config, e.g. https://github.com/flutter/engine/blob/1db92c0ac09b1010535cd0c60f3b661ef203b1cf/shell/platform/linux/config/BUILD.gn, https://source.chromium.org/chromium/chromium/src/+/main:build/linux/unbundle/brotli.gn

[BurningEnlightenment]

i don't see a reason why building with both BUILD_SHARED_LIBS=ON and BUILD_STATIC_LIBS=ON wouldn't be allowed

BUILD_STATIC_LIBS isn't an option natively supported by CMake (see docs and CMake issue). Instead BUILD_SHARED_LIBS switches all libraries whithout an explicit [STATIC | SHARED | MODULE] specification from STATIC to SHARED. CMake doesn't natively support building shared and static variants with a single target and configure. And indeed the alpine package you mentioned patches the snappy buildsystem to introduce BUILD_STATIC_LIBS [1] and a custom snappy_static target [2].

not sure how would that work since the same pkg-config files are used whether you add --static or not.

If you configure the project both times (once for static and once for shared) in a way which generates identical pkg-configs that shouldn't be an issue. And otherwise you've just reached the point where the impedance mismatch between CMake and pkg-config worlds starts to break things.

[selfisekai]

file(GENERATE does not allow to put $<INSTALL_PREFIX> in the contents, as it would be used before the install phase

[BurningEnlightenment]

file(GENERATE does not allow to put $<INSTALL_PREFIX> in the contents, as it would be used before the install phase

Correct, I see how the wording from my previous comment is a bit unclear with regards to this (double configuration dance).

You'll need to either inline the pkg-config template or do a double configuration dance due to the fact that the file(GENERATE INPUT <input-file> form only expands generator expressions but no CMake variables.

What I meant to say: You will need to do a configure_file() in order to expand ${CMAKE_INSTALL_PREFIX} (and incdir, libdir, version, etc.) whose output file you feed into file(GENERATE INPUT to expand the target specific generator expressions. Alternatively you can inline the template as a CMake string with file(GENERATE CONTENT where CMake variables are expanded as usual.