base64
base64 copied to clipboard
add a pkg-config file
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
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
is this correct?
@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).
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
i don't see a reason why building with both
BUILD_SHARED_LIBS=ON
andBUILD_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.
file(GENERATE
does not allow to put $<INSTALL_PREFIX>
in the contents, as it would be used before the install phase
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.