MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0015528CMakeCMakepublic2015-04-22 09:062016-06-10 14:31
Reportermarc.chevrier 
Assigned ToKitware Robot 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake 3.2.2 
Target VersionFixed in Version 
Summary0015528: Enhance find_library to specify which library kind we are looking for
Description
Currently, it is not possible, in an easy way, to specify which kind of library we are looking for when calling find_library.
So if we are searching a static library, and a shared library is also available, this is the shared one which will be found.

Today, to work-around this problem, the following pattern must be used:
set (default_find_library_suffixes ${CMAKE_FIND_LIBRARY_SUFFIXES})
set (CMAKE_FIND_LIBRARY_SUFFIXES ${CMAKE_STATIC_LIBRARY_SUFFIX})
find_library (...)
set (CMAKE_FIND_LIBRARY_SUFFIXES ${default_find_library_suffixes})

which is a bit painful.

I suggest to add a new parameter to specify which kind of library we are looking for.
For example, parameter TYPE which can have values LINK, STATIC or RUNTIME
* LINK: extension .so (Unix) or .lib (Windows) will be used
* STATIC: extension .a (Unix) or .lib (Windows) will be used
* RUNTIME: extension .so (Unix) or .dll (Windows) will be used. This latest case can be useful to locate shared runtime libraries rather than link ones

Whithout this parameter, find_library has same behavior as today.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2015-04-22 09:06marc.chevrierNew Issue
2015-04-22 09:34Brad KingNote Added: 0038577
2015-04-22 10:31marc.chevrierNote Added: 0038580
2015-04-22 10:41Brad KingNote Added: 0038581
2016-06-10 14:29Kitware RobotNote Added: 0042763
2016-06-10 14:29Kitware RobotStatusnew => resolved
2016-06-10 14:29Kitware RobotResolutionopen => moved
2016-06-10 14:29Kitware RobotAssigned To => Kitware Robot
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0038577)
Brad King   
2015-04-22 09:34   
It is not possible to distinguish static libraries and dll import libraries on Windows for MS-compatible tools using just the file name because both end in ".lib". For this reason find_library has never been given such an option as a general-purpose cross-platform feature. See 0001643.

Since CMake 2.6.0 it has been possible to specify specific library file names. I've updated the documentation to mention this:

 Help: Document in find_library how to search for static libraries
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=941e3bd2 [^]
(0038580)
marc.chevrier   
2015-04-22 10:31   
Thanks for the documentation update.
But the proposed approach is not platform agnostic.

On Windows, for sure, it is not possible to distinguish a static library from an import one but it is a platform limitation which must be handled regardless the build tools used (typically by using different names).
CMake can even offers some standard pattern approach to handle this automatically.
Like trying to locate <name>${CMAKE_STATIC_LIBRARY_POSTFIX}.lib first when a static lib is requested on Windows.

So it is a pity to not offer a such option due to ONE platform limitations.
(0038581)
Brad King   
2015-04-22 10:41   
Re 0015528:0038580: A naming convention for static library files one Windows is not useful because:

* If a library comes from a package built by CMake then that package should be provided as documented in the cmake-packages(7) manual where find_library is not needed at all.

* If a library comes from a package not built by CMake then it is unlikely to follow any convention established by CMake.

We do not like to offer features that look first class but are fundamentally broken on a major platform like Windows.
(0042763)
Kitware Robot   
2016-06-10 14:29   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.