Package Details: dlib 19.24.6-2

Git Clone URL: https://aur.archlinux.org/dlib.git (read-only, click to copy)
Package Base: dlib
Description: A general purpose cross-platform C++ library designed using contract programming and modern C++ techniques
Upstream URL: http://dlib.net
Keywords: algebra convolutional deep dlib learning linear machine networks neural
Licenses: custom
Submitter: pingplug
Maintainer: pingplug (swiftscythe, xantares)
Last Packager: xantares
Votes: 38
Popularity: 0.000035
First Submitted: 2015-08-19 09:02 (UTC)
Last Updated: 2024-09-22 09:53 (UTC)

Sources (1)

Pinned Comments

Latest Comments

« First ‹ Previous 1 2 3 4

Xyne commented on 2018-01-12 20:19 (UTC) (edited on 2018-01-12 20:22 (UTC) by Xyne)

Hi,

Thank you for maintaining this package.

Given that the provided CMake configuration files build the shared library and that some projects that rely on Dlib require it, this package should build the object files. If they are truly deprecated then let upstream disable them in CMake. The "standard" or "vanilla" package is whatever upstream sets as default in CMake and that is generally what should be provided in Arch. Users who do not need the libs can disable them. If upstream changes the configuration, then users who need them can instead enable them.

libdlib should then be merged into this package if these changes are made.

Here's a PKGBUILD. Thanks!

# Maintainer: pingplug <pingplug@foxmail.com>
# Contributor: perlawk

pkgname=dlib
_pkgname=dlib
pkgver=19.8
pkgrel=2
pkgdesc="Dlib is a general purpose cross-platform C++ library designed using contract programming and modern C++ techniques."
arch=('i686' 'x86_64')
url="<http://www.dlib.net/>"
license=('Boost Software License')
depends=('glibc' 'blas' 'cuda' 'cudnn' 'giflib' 'lapack' 'libjpeg-turbo' 'libpng' 'neon' 'sqlite')
# optdepends=('blas: for BLAS support'
#             'cuda: for CUDA support'
#             'cudnn: for CUDNN support'
#             'giflib: for GIF support'
#             'lapack: for LAPACK support'
#             'libjpeg-turbo: for JPEG support'
#             'libpng: for PNG support'
#             'neon: for neon support'
#             'sqlite: for sqlite support')
source=("<https://downloads.sourceforge.net/project/dclib/>${_pkgname}/v${pkgver}/${_pkgname}-${pkgver}.tar.bz2")
sha256sums=('dbd31f7b97166e58f366c83fa5127e9fa44c492921558b61ce63a7d775be696b')

build() {
  cd "${srcdir}/${_pkgname}-${pkgver}"
  mkdir -p -- build
  cd -- build
  cmake \
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_INSTALL_LIBDIR=lib
    ..
  make -j $(($(nproc) + 1))
}

package() {
  cd "${srcdir}/${_pkgname}-${pkgver}/build"
  make DESTDIR="$pkgdir" install
  install -Dm644 ../dlib/LICENSE.txt "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
}

I have left the optdepends for future reference in anticipation of library deprecation. You can of course move any deps back to optdeps or to makedeps if the compiled library does not require them after installation. I didn't check.

rib commented on 2017-11-22 01:48 (UTC)

I ended up creating an alternative 'libdlib' package that installs headers, a libdlib.so library + 'dlib-1' pkg-config file: https://aur.archlinux.org/packages/libdlib

rib commented on 2017-11-22 00:37 (UTC)

Although dlib is possible to use without compiling a libdlib.so it seems awkward to make a package which doesn't install the pkg-config files so projects can't discover this style of dlib packaging. Although I understand the idea of encouraging the use of dlib without needing a shared library; personally I'd still prefer a package that would install a library, headers and pkg-config file, more consistent with other packages, and other distros (at least Ubuntu - I didn't check any others). For the case where dlib is used without a pre-built library the upstream documentation suggests compiling dlib/all/source.cpp which isn't installed via cmake (which is why this package installs them directly I suppose) but with that inconsistency then it seems unlikely much software will be written to expect that /usr/include/dlib/all/source.cpp exists if they want to be easily buildable across a range of distros.

yxchng commented on 2017-09-06 06:31 (UTC)

Why package a library without .so files? How should I use this package?

joker512 commented on 2017-02-09 15:55 (UTC)

Why don't you build .a and .so files in this package?

« First ‹ Previous 1 2 3 4