]> granicus.if.org Git - libjpeg-turbo/commit
Build: Set install dirs in a more GNU-friendly way
authorDRC <information@libjpeg-turbo.org>
Wed, 7 Dec 2016 16:54:54 +0000 (10:54 -0600)
committerDRC <information@libjpeg-turbo.org>
Wed, 7 Dec 2016 22:55:38 +0000 (16:55 -0600)
commitd681fa76264318a7292477d170889a62580508b1
tree4dfde195d53a9d9deb4b3a15c9dddd259d65b489
parentff05b6e0deb91c64d2607589846b1467d6ce88a0
Build: Set install dirs in a more GNU-friendly way

This builds upon the existing GNUInstallDirs module in CMake but adds
the following features to that module:

- The ability to override the defaults for each install directory
  through a new set of variables (`CMAKE_INSTALL_DEFAULT_*DIR`).

  Before operating system vendors began shipping libjpeg-turbo, it was
  meant to be a run-time drop-in replacement for the system's
  distribution of libjpeg, so it has traditionally installed itself
  under /opt/libjpeg-turbo on Un*x systems by default.  On Windows, it
  has traditionally installed itself under %SystemDrive%\libjpeg-turbo*,
  which is not uncommon behavior for open source libraries (open source
  SDKs tend to install outside of the Program Files directory so as to
  avoid spaces in the directory name.)  At least in the case of Un*x,
  the install directory behavior is based somewhat on the Solaris
  standard, which requires all non-O/S packages to install their files
  under /opt/{package_name}.  I adopted that standard for VirtualGL and
  TurboVNC while working at Sun, because it allowed those packages to be
  located under the same directory on all platforms.  I adopted it for
  libjpeg-turbo because it ensured that our files would never conflict
  with the system's version of libjpeg.  Even though many Un*x
  distributions ship libjpeg-turbo these days, not all of them ship the
  TurboJPEG API library or the Java classes or even the latest version
  of the libjpeg API library, so there are still many cases in which it
  is desirable to install a separate version of libjpeg-turbo than the
  one installed by the system.  Furthermore, installing the files under
  /opt mimics the directory structure of our official binary packages,
  and it makes it very easy to uninstall libjpeg-turbo.

  For these reasons, our build system needs to be able to use
  non-GNU-compliant defaults for each install directory if
  `CMAKE_INSTALL_PREFIX` is set to the default value.

- For each directory variable, the module now detects changes to
  `CMAKE_INSTALL_PREFIX` and changes the directory variable accordingly,
  if the variable has not been changed by the user.

  This makes it easy to switch between our "official" directory
  structure and the GNU-compliant directory structure "on the fly"
  simply by changing `CMAKE_INSTALL_PREFIX`.  Also, this new mechanism
  eliminated the need for the crufty mechanism that previously did the
  same thing just for the library directory variable.

  How it should work:
  - If a dir variable is unset, then the module will set an internal
    property indicating that the dir variable was initialized to its
    default value.
  - If the dir variable ever diverges from its default value, then the
    internal property is cleared, and it cannot be set again without
    unsetting the dir variable.
  - If the install prefix changes, and if the internal property
    indicates that the dir variable is still set to its default value,
    and if the dir variable's value is not being manually changed at the
    same time that the install prefix is being changed, then the dir
    variable's value is automatically changed to the new default value
    for that variable (as determined by the new install prefix.)

- The directory variables are now always cached, regardless of whether
  they were set on the command line or not.  This ensures that they can
  easily be examined and modified after being set, regardless of how they
  were set.

  This was made possible by the introduction of the aforementioned
  `CMAKE_INSTALL_DEFAULT_*DIR` variables.

- Improved directory variable documentation (based on descriptions at
  https://www.gnu.org/prep/standards/html_node/Directory-Variables.html)

- The module now allows "<DATAROOTDIR>" to be used as a placeholder in
  relative directory variables.

  It is replaced "on the fly" with the actual path of
  `CMAKE_INSTALL_DATAROOTDIR`.

This should more closely mimic the behavior of the old autotools build
system while retaining our customizations to it, and it should retain
the behavior of the old CMake build system.

Closes #124
13 files changed:
BUILDING.md
CMakeLists.txt
cmakescripts/GNUInstallDirs.cmake [new file with mode: 0644]
java/CMakeLists.txt
java/org/libjpegturbo/turbojpeg/TJLoader-unix.java.in
release/libjpeg.pc.in
release/libturbojpeg.pc.in
release/makecygwinpkg.in
release/makedpkg.in
release/makemacpkg.in
release/rpm.spec.in
release/uninstall.in
sharedlib/CMakeLists.txt