MantisBT - CMake
View Issue Details
0003976CMakeCMakepublic2006-10-25 05:302011-06-17 12:38
Frederic Heem 
Brad King 
lowfeaturealways
closedfixed 
 
CMake 2.8.5CMake 2.8.5 
0003976: make the install location variables builtin cmake
Would it be possible to add the install location variables built-in cmake. CMAKE_INSTALL_PREFIX is already built-in
The additional variables could be names:
CMAKE_BINDIR
CMAKE_SBINDIR
CMAKE_EXECDIR
CMAKE_DATADIR
CMAKE_SYSCONFDIR
CMAKE_SHAREDSTATEDIR
CMAKE_LOCALSTATEDIR
CMAKE_LIBDIR
CMAKE_INCLUDEDIR
CMAKE_OLDINCLUDEDIR
CMAKE_INFODIR
CMAKE_MANDIR

The main reason is that various project shall use the same variable to enforce consistency across package.
No tags attached.
diff cmake-CMAKE_DATADIR-CMAKE_SYSCONFDIR-CMAKE_MANDIR-20061025.diff (936) 1969-12-31 19:00
https://public.kitware.com/Bug/file/711/cmake-CMAKE_DATADIR-CMAKE_SYSCONFDIR-CMAKE_MANDIR-20061025.diff
? CMakeInstallDirs.cmake (1,889) 1969-12-31 19:00
https://public.kitware.com/Bug/file/715/CMakeInstallDirs.cmake
? CMakeInstallDirs.cmake_20061117 (3,690) 1969-12-31 19:00
https://public.kitware.com/Bug/file/743/CMakeInstallDirs.cmake_20061117
? CMakeInstallDirs_full.cmake (14,371) 2011-02-09 04:32
https://public.kitware.com/Bug/file/3686/CMakeInstallDirs_full.cmake
? GNUInstallDirs.cmake (14,959) 2011-02-21 05:50
https://public.kitware.com/Bug/file/3712/GNUInstallDirs.cmake
? GNUInstallDirs_2.cmake (12,758) 2011-02-23 05:00
https://public.kitware.com/Bug/file/3718/GNUInstallDirs_2.cmake
? GNUInstallDirs_3.cmake (12,820) 2011-02-23 05:05
https://public.kitware.com/Bug/file/3719/GNUInstallDirs_3.cmake
? GNUInstallDirs_4.cmake (8,172) 2011-02-23 08:48
https://public.kitware.com/Bug/file/3722/GNUInstallDirs_4.cmake
Issue History
2007-10-12 11:15Bill HoffmanStatusnew => assigned
2011-02-09 04:32Nikita KrupenkoFile Added: CMakeInstallDirs_full.cmake
2011-02-09 05:05Nikita KrupenkoNote Added: 0025351
2011-02-18 03:36Nikita KrupenkoNote Added: 0025468
2011-02-18 08:46Brad KingNote Added: 0025470
2011-02-21 05:50Nikita KrupenkoFile Added: GNUInstallDirs.cmake
2011-02-21 06:03Nikita KrupenkoNote Added: 0025527
2011-02-21 06:10Nikita KrupenkoNote Edited: 0025527bug_revision_view_page.php?bugnote_id=25527#r209
2011-02-22 17:35Brad KingNote Added: 0025553
2011-02-23 05:00Nikita KrupenkoFile Added: GNUInstallDirs_2.cmake
2011-02-23 05:05Nikita KrupenkoFile Added: GNUInstallDirs_3.cmake
2011-02-23 05:07Nikita KrupenkoNote Added: 0025558
2011-02-23 08:19Brad KingNote Added: 0025559
2011-02-23 08:48Nikita KrupenkoFile Added: GNUInstallDirs_4.cmake
2011-02-23 08:54Nikita KrupenkoNote Added: 0025562
2011-03-02 05:11Nikita KrupenkoNote Added: 0025619
2011-03-02 07:09Brad KingNote Added: 0025620
2011-03-23 14:46Brad KingNote Added: 0025889
2011-03-23 14:46Brad KingStatusassigned => closed
2011-03-23 14:46Brad KingResolutionreopened => fixed
2011-06-17 12:38David ColeFixed in Version => CMake 2.8.5
2011-06-17 12:38David ColeTarget Version => CMake 2.8.5

Notes
(0005531)
Frederic Heem   
2006-10-25 06:16   
Pleas find attached a patch that add CMAKE_DATADIR, CMAKE_SYSCONFDIR and CMAKE_MANDIR. Once this patch os reviews, other variables will be added.
(0005535)
Brad King   
2006-10-25 10:08   
Sorry, but I don't think we should add these. Implementing them requires support from CMakeLists.txt code. Many projects just won't use them and then it will look like CMake bugs. If you want to use them in all your projects or add a section to the Wiki describing your convention you are welcome to do so.

Also I don't think they will be appropriate in all cases. Each project should define its own such variables (FOO_BINDIR, FOO_SBINDIR, etc.). Then when projects are nested then the parent project can tell its child where to install.
(0005539)
Frederic Heem   
2006-10-25 10:36   
The autotool buildtool provides these variables by default. I agree that not all packages uses /etc, /var etc .. but there are still a lot of packages that uses them and having a common naming convertion is definitely better that allowing cmake users to create new imcompatible names.
Anyway, these variables can be listed in the "advanced" section.
If you think FOO_BINDIR, FOO_SBINDIR etc .. are better, so CMAKE_INSTALL_PREFIX must be changed to FOO_INSTALL_PREFIX for consistency
These variables allows better granularity over where to install files. For instance, suppose the install prefix is /usr, if ${CMAKE_INSTALL_PREFIX}/../etc is used to set the /etc, then it will no longer work when the install prefix is /usr/local. How do you handle the corner case of /etc and /var ?
Moreover, instead of using ${CMAKE_INSTALL_PREFIX}/share, one can use ${CMAKE_DATADIR}, which is shorter and more flexible.

(0005540)
Brad King   
2006-10-25 10:49   
Cases like /etc and /var are handled by the INSTALL command (not the old INSTALL_TARGETS, INSTALL_FILES, and INSTALL_PROGRAMS commands though). If the DESTINATION keyword is a relative path it is treated relative to CMAKE_INSTALL_PREFIX. Otherwise the full path given is used. From this perspecitve CMAKE_INSTALL_PREFIX plays a specific role which is why it must have a single name across all projects.

These other variables you are proposing do not have such a special role and can easily be defined on a per-project basis. I agree that standardizing these names is a good idea but I don't want to show the variables for projects that don't support them.

Let's instead create a module like CMakeInstallDirs.cmake that comes with CMake and can be included to create all these variables. Then it would be up to the project to use them and if it doesn't we can blame the project and not CMake. How does that sound?
(0005543)
Frederic Heem   
2006-10-25 11:12   
Ok, let's create CMakeInstallDirs.cmake.
Just to let you know that all my cmake based applications use at least /usr/share to store data, so. 3 apps out of 3 will have to include CMakeInstallDirs.cmake
Why not asking the mailing list to find out the opinion of cmake users?
(0005545)
Brad King   
2006-10-25 11:25   
The point is not whether all projects should include this file, it is the fact that some projects (all existing ones) don't pay attention to these variables. The only way to make this change compatible and clean is to require projecst that want the feature to enable it (by including the file).
(0005546)
Brad King   
2006-10-25 11:41   
Let's make sure we agree on the interface here. I think the names should start in CMAKE_INSTALL_ instead of just CMAKE_ so they all stay together in the setup dialogs.

The variables should be used like this:

INSTALL(... DESTINATION ${CMAKE_INSTALL_BINDIR})

The default in this case would be "bin" so that it installs relative to the install prefix. If the user changes it to "/my/bin" then it would install to that absolute path. I think this is consistent with the auto* behavior.

So what should the defaults be for all of these?

I've seen this set in auto* scripts:

prefix = /usr/local
exec_prefix = ${prefix}
bindir = ${exec_prefix}/bin
sbindir = ${exec_prefix}/sbin
libexecdir = ${exec_prefix}/libexec
datadir = ${prefix}/share
sysconfdir = ${prefix}/etc
sharedstatedir = ${prefix}/com
localstatedir = ${prefix}/var
libdir = ${exec_prefix}/lib
infodir = ${prefix}/info
mandir = ${prefix}/man
includedir = ${prefix}/include
oldincludedir = /usr/include

Is the separation of prefix and exec_prefix meant to separate platform-independent things from platform-dependent things?
(0005556)
Frederic Heem   
2006-10-26 09:25   
Please have a look at CMakeInstallDirs.cmake
By the way, since it defines some variable that 99.9% of application will use (at least CMAKE_INSTALL_BINDIR). I'm conviced it would be better to include CMakeInstallDirs.cmake by default.
(0005560)
Brad King   
2006-10-26 11:53   
The CMAKE_INSTALL_PREFIX variable should not actually be referenced by the module:

SET(CMAKE_INSTALL_BINDIR "${CMAKE_INSTALL_PREFIX}/bin"
    CACHE PATH ${CMAKE_INSTALL_BINDIR_DOC})

should be

SET(CMAKE_INSTALL_BINDIR "bin"
    CACHE PATH ${CMAKE_INSTALL_BINDIR_DOC})

The INSTALL command will automatically take care of the switch between full path and prefix depending on the user's setting of this cache entry.
(0005792)
Enrico Scholz   
2006-11-25 13:17   
My suggestion: remove any prefix (CMAKE, CMAKE_INSTALL, ...) and use
the standardized variable names ('bindir', 'libdir', ...).

Why should CMAKE_INSTALL_PREFIX not be referenced in CMakeLists.txt?
Is there some special logic behind it?

I am not sure whether the special logic for /etc + /var shall be
implemented (when ${prefix}=/usr -> use /etc, else ${prefix}/etc).
auto* projects worked perfectly without such a logic and implicit
logic hurts usually more than you gain with it.
(0005795)
Enrico Scholz   
2006-11-25 13:37   
Not using CMAKE_INSTALL_PREFIX would cause problems in situations like

| ADD_DEFINITION(-DPKGLIBDIR="${pkglibdir}")

This would define PKGLIBDIR to a relative "lib/PACKAGE" path while program expects an absolute path.
(0025351)
Nikita Krupenko   
2011-02-09 05:05   
I agree, that variables for install directories should not contain prefix and be only relative. But also, full path may be very useful, for example, when configuring some files like scripts, that should contain some absolute path. So I found solution by defining two types of variables - relative and absolute. For example, default values:

CMAKE_INSTALL_BINDIR => "bin"
CMAKE_INSTALL_FULL_BINDIR => ${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_BINDIR} => "/usr/bin"

"FULL" may be replaced with "ABSOLUTE" or something else, if required.

I created module to be autotools-compliant, so it contains all directories, that available in recent versions and by default use the same paths.

It will be good, if this module will be shipped with CMake, because default paths may be configured during build of CMake and contain appropriate values for system. For example, for usual Linux systems docdir is "/usr/share/doc", but for SUSE Linux it is "/usr/share/doc/packages", so in the module it should be:
CMAKE_INSTALL_DOCDIR => "${CMAKE_INSTALL_DATAROOTDIR}/doc/packages"
instead of:
CMAKE_INSTALL_DOCDIR => "${CMAKE_INSTALL_DATAROOTDIR}/doc"

My version of module called "CMakeInstallDirs_full.cmake"
(0025468)
Nikita Krupenko   
2011-02-18 03:36   
Brad King:
> Let's instead create a module like CMakeInstallDirs.cmake that comes with CMake and can be included to create all these variables. Then it would be up to the project to use them and if it doesn't we can blame the project and not CMake.

Can you look at my version of module (CMakeInstallDirs_full.cmake)?
It would be nice, if CMake has standard module for this directories.
(0025470)
Brad King   
2011-02-18 08:46   
Re 0003976:0025468: Good start.

It looks like the set of variables is actually a GNU standard rather than an autotools convention:

  http://www.gnu.org/prep/standards/html_node/Directory-Variables.html [^]

I suggest that the module be named "GNUInstallDirs.cmake" and document that it provides the fields needed to achieve GNU standard installation layout.

The variables with "FULL" in their name should not be CACHE variables. They should be set as normal variables using code like this:
 if(IS_ABSOLUTE "${CMAKE_INSTALL_BINDIR}")
   set(CMAKE_INSTALL_FULL_BINDIR "${CMAKE_INSTALL_BINDIR}")
 else()
   set(CMAKE_INSTALL_FULL_BINDIR "${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_BINDIR}")
 endif()

That way they can change automatically as the corresponding cache entry changes. The module documentation should state that the absolute paths are based on the value of CMAKE_INSTALL_PREFIX as set when the module is included.
(0025527)
Nikita Krupenko   
2011-02-21 06:03   
(edited on: 2011-02-21 06:10)
I agree with your suggestions. New version uploaded (GNUInstallDirs.cmake).

I've changed DOCDIR to be DATAROOTDIR/doc/PROJECT_NAME.

Also, I've not included some variables from specification: lispdir, man1dir, man2dir, manext, man1ext, man2ext. In autotools, only lispdir is used, and at now, it cannot be set in common way (i.e. with --lispdir option), it should be set with option --with-lispdir. So, I don't sure if this variables are needed.

Also, I think, that variables, that was set by user, may not me marked as advanced.

(0025553)
Brad King   
2011-02-22 17:35   
Re 0003976:0025527:

Thanks. A few more comments:

- The top still documents it as named "CMakeInstallDirs"

- Please try putting this module in the CMake Modules directory and running "cmake --help-module GNUInstallDirs". Adjust the documentation formatting to make that look nice. Separate the copyright block by a truly blank line so it does not get included in the docs.

- There is no need for mark_as_advanced on the (now) non-cache FULL variables

- The else() and endif() lines do not need to duplicate the expression, just use literal "else()" and "endif()"

- Please use 2 spaces for indentation instead of hard TABs
(0025558)
Nikita Krupenko   
2011-02-23 05:07   
Ok, module fixed and uploaded new version (GNUInstallDirs_3.cmake).
(0025559)
Brad King   
2011-02-23 08:19   
Re 0003976:0025558:

Great! A few more details:

- In order to distribute this with CMake I will replace the license block by one like this:
  http://cmake.org/gitweb?p=cmake.git;a=blob;f=Modules/FindOpenSSL.cmake;hb=v2.8.4#l11 [^]
  It will still have your copyright line but will reference CMake's BSD licesnse.
  Is that acceptable?

- The FULL variables should not have the "PATH" or documentation arguments because those are only for CACHE entries and otherwise end up in the value itself.
  It can also be simplified with foreach() since there is nothing specific about any individual entry:

  foreach(v
      BINDIR
      SBINDIR
      LIBEXECDIR
      #...
      )
    if(IS_ABSOLUTE "${CMAKE_INSTALL_${v}}")
      set(CMAKE_INSTALL_FULL_${v} "${CMAKE_INSTALL_${v}}")
    else()
      set(CMAKE_INSTALL_FULL_${v} "${CMAKE_INSTALL_PREFIX}/${CMAKE_INSTALL_${v}}")
    endif()
  endforeach()
(0025562)
Nikita Krupenko   
2011-02-23 08:54   
Edited module, uploaded new version (GNUInstallDirs_4.cmake)

You may correct license block, as needed.
(0025619)
Nikita Krupenko   
2011-03-02 05:11   
Is there any news?
(0025620)
Brad King   
2011-03-02 07:09   
Re 0003976:0025619: I have the module committed locally in a topic branch along with some documentation updates. I need to go over it with some other developers before merging to upstream CMake.
(0025889)
Brad King   
2011-03-23 14:46   
I merged it with a few tweaks and new documentation:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a262fe09 [^]
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=11431c67 [^]
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c2bf48ef [^]

Thanks for your help.