Wouldn't CMAKE_STATIC_LIBRARY_PREFIX
be a better solution? This way you can use add_library(foo foo.c)
and let the user decide whether to build shared or static via BUILD_SHARED_LIBS
.
Or is there a target-specific option for that automatism similar to the define used for exports?
See also my comment on whether it makes sense to find "lib" prefixes by default also on Windows.
A widely used convention is to use
foo.{lib,dll}
for the shared library andlibfoo.lib
for the static library.
CMake doesn't support that by default, does it? Wouldn't it make sense to keep "lib" in CMAKE_FIND_LIBRARY_PREFIXES
for this "widely used convention"? And maybe document this clearly so other build system authors also know about this and the convention can be *.lib
for MSVC/UCRT and *.a
for GCC?
FWIW, Meson explicitly ignores the pkg-config provided by Strawberry Perl in PATH because it is completely broken. CMake should probably do the same thing.
Can you elaborate in which way that pkg-config is "completely broken"? As I understand it does exactly what it is meant to do and works well with the GCC and libs from StrawberryPerl
In the end, I think it's up to the user to configure their environment correctly to intentionally pick the things they want: whether it's pkg-config or libs from the correct prefix, etc. If the user wants to link to
libfoo.a
when using the MSVC ABI, they should be allowed to.
Correct, it is up to the user to include or exclude things where the "automagic" fails to pick the desired stuff. There is CMAKE_IGNORE_PATH
for excluding and various other cache variables to set paths to executables and libraries. And you have CMAKE_FIND_LIBRARY_PREFIXES
and CMAKE_FIND_LIBRARY_SUFFIXES
to tune the auto-search.
Also related: The same environment (GHA windows-2019) has a C:/Strawberry/perl/bin/pkg-config.bat
which is found and will then add e.g. C:/Strawberry/c/lib/libharfbuzz.a
when asked to find it via pkg_check_modules(PC_HARFBUZZ harfbuzz>=0.9.7)
I guess a workaround is to add C:/Strawberry/c/lib
to CMAKE_IGNORE_PATH
as -DCMAKE_IGNORE_PREFIX_PATH=C:/Strawberry/c
is not enough to make it not find the library through pkg-config (which is in PATH and hence found by find_program
in FindPkgConfig.cmake
)
Just mentioning this so someone can verify that the revert of the change also avoids it picking up *.a
files via pkg-config.
Components were incorrectly reported as found because component_found
is set to a string containing the variable name which is a truethy value.
Fix by simply merging the setter of component_found
with the reporting setter instead of checking component_found OR component_found_compat
which is overly verbose anyway.
Alexander Grund (669b6a37) at 30 Jun 13:37
FindICU: Fix component reporting logic
... and 18375 more commits
@brad.king Ran into this again: Even when using absolute paths it may not work: When an executable (e.g. test binary) links to a shared library target which privately links to another shared library target the executable fails to run, even through CTest. It seemingly is able to load the first shared library but not its (private) dependency. Seems it uses the absolute paths to load the first library and does not add its path to the runtime search path (in my specific case both libraries are installed into the same folder)
This fixes a simple C&P bug
To avoid this in the future I refactored this to create a list and iterate over that.
Topic-rename: irsl-intel
Alexander Grund (4a7232e2) at 30 Jul 10:24
Avoid duplication of lib folders
Alexander Grund (ab2b0845) at 30 Jul 10:06
Fix check of path to intel redistdir
... and 14495 more commits
Alexander Grund (85550a56) at 06 Jul 10:25
Resolve entries of $CPATH as late as possible
... and 1 more commit
Alexander Grund (a97516c9) at 06 Jul 10:24
Resolve entries of $CPATH as late as possible
Alexander Grund (2945c6c6) at 06 Jul 10:20
Resolve entries of $CPATH as late as possible
... and 14087 more commits
This is very similar to https://cmake.org/cmake/help/latest/release/3.14.html?highlight=cpath#id4
If an include directory /tmp/foo/include
is added and /tmp/bar/include
is in $CPATH
with symlink /tmp/foo
->/tmp/bar
then CMake does omit the include argument to the compiler.
Following CMakeLists:
cmake_minimum_required(VERSION 2.8.12)
project(foo)
include_directories(SYSTEM /tmp/foo/include)
add_executable(foo main.cpp)
mkdir -p /tmp/bar/include
ln -s bar /tmp/foo
echo 'int main(){}' > main.cpp
CPATH=/tmp/bar/include cmake . && make VERBOSE=1
This shows: g++ -O3 -o CMakeFiles/foo.dir/main.cpp.o -c /dev/shm/test/main.cpp
-> -isystem is missing
This is a real problem due to warning suppression.
Note that the same happens for the case without SYSTEM
: Without the CPATH setting the -I
is added, with CPATH it is not