|
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
|
|
|
|
|
(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
|
|
|
cmake-CMAKE_DATADIR-CMAKE_SYSCONFDIR-CMAKE_MANDIR-20061025.diff (936) 1969-12-31 19:00
CMakeInstallDirs.cmake (1,889) 1969-12-31 19:00