Closed mara004 closed 1 year ago
As far as I remember this is the convention. I just looked at CMake's documentation and it goes in the same way:
LIBRARY
Target artifacts of this kind include:
- Shared libraries, except
- DLLs (these go to
RUNTIME
, see below),- on macOS when marked as
FRAMEWORK
(see below).
RUNTIME
- Target artifacts of this kind include:
- Executables (except on macOS when marked as
MACOSX_BUNDLE
, seeBUNDLE
below);- DLLs (on all Windows-based systems including Cygwin; note that the accompanying import libraries are of kind
ARCHIVE
).
Target Type GNUInstallDirs Variable Built-In Default RUNTIME ${CMAKE_INSTALL_BINDIR} bin LIBRARY ${CMAKE_INSTALL_LIBDIR} lib ARCHIVE ${CMAKE_INSTALL_LIBDIR} lib PRIVATE_HEADER ${CMAKE_INSTALL_INCLUDEDIR} include PUBLIC_HEADER ${CMAKE_INSTALL_INCLUDEDIR} include FILE_SET (type HEADERS) ${CMAKE_INSTALL_INCLUDEDIR} include
Indeed, it is also for conda:
Unix-style packages on Windows, which are usually statically linked to executables, are built in a special
Library
directory under the build prefix. The environment variables listed in the following table are defined only on Windows.
CYGWIN_PREFIX
Same as PREFIX, but as a Unix-style path, such as
/cygdrive/c/path/to/prefix
.LIBRARY_BIN
<build prefix>\Library\bin
.LIBRARY_INC
<build prefix>\Library\include
.LIBRARY_LIB
<build prefix>\Library\lib
.LIBRARY_PREFIX
<build prefix>\Library
.SCRIPTS
<build prefix>\Scripts
.
mara004 commented 1 year agoSince this is the convention I think it's fine as-is. Just something packagers need to bear in mind.
For all non-windows platforms, the actual binary is in
lib/
. For windows, it is inbin/
, whilelib/
contains a specialpdfium.dll.lib
file. That's a bit unexpected/confusing and needs special handling by packagers.How about putting both files in
lib/
?