CMake: Counterpart to configure option --sysconfdir missing
Moderator: Moderator Team
CMake: Counterpart to configure option --sysconfdir missing
Using CMake setting a directory correlating with configure option --sysconfdir doesn't seem to be possible. So when CMake variable CMAKE_INSTALL_PREFIX is set to /usr, which is sort of mandatory on virtually all Linux systems, the various configuration files *.cfg end up in /usr/etc/dcmtk/ which does not make sense.
Thus a counterpart of the said configure option, possibly implemented as CMake variable as well, would be good to have.
Thus a counterpart of the said configure option, possibly implemented as CMake variable as well, would be good to have.
-
- DCMTK Developer
- Posts: 2055
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
Re: CMake: Counterpart to configure option --sysconfdir miss
Hi,
not sure whether setting the installation prefix to /usr is often done by people that build DCMTK. I assume that it is more common to install DCMTK to /usr/local which is what DCMTK does per default.
However, I agree that some people might want to have the configuration files of locally installed packages go to /etc directly instead of hiding them in /usr/local/... .
Some features of our traditional configure scripts have not been ported yet to CMake (which we introduced later, originally as an alternative to Visual Studio project files we manually created earlier). This is already noted in our issue tracker (issue #385). I added the issue described to the list of features linked on the bug tracker (access only for registered users) that need to be ported.
Thanks for the report,
Michael
not sure whether setting the installation prefix to /usr is often done by people that build DCMTK. I assume that it is more common to install DCMTK to /usr/local which is what DCMTK does per default.
However, I agree that some people might want to have the configuration files of locally installed packages go to /etc directly instead of hiding them in /usr/local/... .
Some features of our traditional configure scripts have not been ported yet to CMake (which we introduced later, originally as an alternative to Visual Studio project files we manually created earlier). This is already noted in our issue tracker (issue #385). I added the issue described to the list of features linked on the bug tracker (access only for registered users) that need to be ported.
Thanks for the report,
Michael
-
- DCMTK Developer
- Posts: 2055
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
Re: CMake: Counterpart to configure option --sysconfdir miss
P.S: Does CMake option DCMTK_INSTALL_ETCDIR the trick?
Re: CMake: Counterpart to configure option --sysconfdir miss
I respectfully disagree.not sure whether setting the installation prefix to /usr is often done by people that build DCMTK. I assume that it is more common to install DCMTK to /usr/local
Rather, DCMTK is meant to be used as a regular system library most of the time and as such installed to /usr/lib or variants like /usr/lib<architecture> but hardly ever to /usr/local/. Arch Linux, Debian, Fedora and openSUSE all are dealing with DCMTK that way.
Basically it does, yes. Two remarks:P.S: Does CMake option DCMTK_INSTALL_ETCDIR the trick?
The variable's name is a bit misleading. "ETCDIR" suggests it's about the path of a directory "etc". But it's the path of the directory where the various configuration files *.cfg should go. In other words, the variable's value will be something like /etc/dcmtk most of the time, not /etc/ as suggested by the name. Would it by any chance make sense to rename it to something like DCMTK_INSTALL_SYSCONFDIR similar to configure option --sysconfdir which clearly states what the setting is about?
Also, the variable seems a bit hidden. According to my (not too thorough) CMake knowledge it's possible to depict CMake variables by lines lines like
Code: Select all
option(VTK_ENABLE_KITS "Build VTK using kits instead of modules." OFF)
-
- DCMTK Developer
- Posts: 2517
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: CMake: Counterpart to configure option --sysconfdir miss
Only answering to a certain aspect of your posting (I guess that Michael will answer to the others):
Anyway, it would probably also help if the INSTALL file would be enhanced in this regard. There is a nice Howto in the support Wiki but I'm not sure how many users are aware of this.
In my opinion, the name of the variable does not really matter since the description of this CMake variable clearly says: "Installation sub-directory for configuration files." The name is more related to the sub-directory "etc", which is contained in each DCMTK module directory (e.g. "dcmdata/etc"), than to the system directory "/etc". Also please note that this variable is marked as "advance", so it is only visible on the user interface (ccmake or cmake-gui) if the advanced mode is enabled.The variable's name is a bit misleading. "ETCDIR" suggests it's about the path of a directory "etc". But it's the path of the directory where the various configuration files *.cfg should go. [...] Also, the variable seems a bit hidden.
There used to be a main CMakeLists.txt file in DCMTK's main directory where all variables were specified but this changed some time ago. Unfortunately, I can't remember why since I wasn't the person who introduced the dcmtk/CMake sub-directory... I personally still prefer the good old GNU AutoconfIn particular if stated in CMakeLists.txt in the code's root directory lines like this provide a good hint which variables are available and how to make use of them.
Anyway, it would probably also help if the INSTALL file would be enhanced in this regard. There is a nice Howto in the support Wiki but I'm not sure how many users are aware of this.
Re: CMake: Counterpart to configure option --sysconfdir miss
Variable DCMTK_INSTALL_ETCDIR is listed both by 'cmake -LAH' and cmake-gui and doing the trick, the corresponding help text is explaining well what the variable is doing.
I've only missed all this as I wasn't searching for the proper strings so basically this thread was dealing with a non-issue. Sorry for the noise.
Maybe it would indeed be helpful to mention the variable and/or the Howto linked above in the code's file INSTALL.
Personally, I still think the variable's name isn't really suitable, in particular as it's completely different than --sysconfdir used so far. Considering what's said above this doesn't represent a real problem any longer, though, but maybe is just a matter of taste or even some bikeshedding.
I've only missed all this as I wasn't searching for the proper strings so basically this thread was dealing with a non-issue. Sorry for the noise.
Maybe it would indeed be helpful to mention the variable and/or the Howto linked above in the code's file INSTALL.
Personally, I still think the variable's name isn't really suitable, in particular as it's completely different than --sysconfdir used so far. Considering what's said above this doesn't represent a real problem any longer, though, but maybe is just a matter of taste or even some bikeshedding.
-
- OFFIS DICOM Team
- Posts: 318
- Joined: Mon, 2014-03-03, 09:51
- Location: Oldenburg, Germany
Re: CMake: Counterpart to configure option --sysconfdir miss
Do you by chance know what other CMake based projects use as the name for such a variable?
Re: CMake: Counterpart to configure option --sysconfdir miss
Grepping through the Arch Linux PKGBUILDS suggests SYSCONFDIR, <software>_INSTALL_SYSCONFDIR and CMAKE_INSTALL_SYSCONFDIR are rather commonly used.
The latter is corresponding with CMake module GNUInstallDirs.
If I'm not mistaken the variables covered by that module are not referring to the particular directories used by the applications but to the superordinate ones. E. g. CMAKE_INSTALL_SYSCONFDIR does not point to /etc/someapp but to /etc only.
Obviously this is in contrast to the current behaviour of DCMTK_INSTALL_ETCDIR.
The latter is corresponding with CMake module GNUInstallDirs.
If I'm not mistaken the variables covered by that module are not referring to the particular directories used by the applications but to the superordinate ones. E. g. CMAKE_INSTALL_SYSCONFDIR does not point to /etc/someapp but to /etc only.
Obviously this is in contrast to the current behaviour of DCMTK_INSTALL_ETCDIR.
-
- OFFIS DICOM Team
- Posts: 318
- Joined: Mon, 2014-03-03, 09:51
- Location: Oldenburg, Germany
Re: CMake: Counterpart to configure option --sysconfdir miss
Great, is anybody against introducing these variables then, replacing DCMTK_INSTALL_ETCDIR?pmattern wrote:Grepping through the Arch Linux PKGBUILDS suggests SYSCONFDIR, <software>_INSTALL_SYSCONFDIR and CMAKE_INSTALL_SYSCONFDIR are rather commonly used.
As Jörg indicated, DCMTK's CMake setup started as a workaround for Visual Studio that tried to most closely mimic the existing Autoconf behaviour. This doens't mean we can't use more appropriate CMake ways instead though, as long as we are careful enough during the conversion.pmattern wrote:If I'm not mistaken the variables covered by that module are not referring to the particular directories used by the applications but to the superordinate ones. E. g. CMAKE_INSTALL_SYSCONFDIR does not point to /etc/someapp but to /etc only.
Obviously this is in contrast to the current behaviour of DCMTK_INSTALL_ETCDIR.
-
- DCMTK Developer
- Posts: 2517
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: CMake: Counterpart to configure option --sysconfdir miss
As I wrote earlier (see above), I don't see any advantage in renaming the variables. So, I would vote against it.Great, is anybody against introducing these variables then, replacing DCMTK_INSTALL_ETCDIR?
Also please note that there is a reason for the current naming scheme. The following excerpt is from "CMake/dcmtkPrepare.cmake":
Code: Select all
SET(DCMTK_INSTALL_BINDIR "bin" CACHE STRING "Installation sub-directory for binary executables.")
SET(DCMTK_INSTALL_INCDIR "include" CACHE STRING "Installation sub-directory for header files.")
SET(DCMTK_INSTALL_LIBDIR "lib" CACHE STRING "Installation sub-directory for object code libraries.")
# CMake's files (DCMTKTarget.cmake, DCMTKConfigVersion.cmake and DCMTKConfig.cmake) are installed
# to different installation paths under Unix- and Windows-based systems
IF(UNIX)
SET(DCMTK_INSTALL_CMKDIR "lib/cmake/dcmtk" CACHE STRING "Installation sub-directory for CMake files.")
ELSEIF(WIN32)
SET(DCMTK_INSTALL_CMKDIR "cmake" CACHE STRING "Installation sub-directory for CMake files.")
ENDIF(UNIX)
SET(DCMTK_INSTALL_ETCDIR "etc/dcmtk" CACHE STRING "Installation sub-directory for configuration files.")
SET(DCMTK_INSTALL_DATDIR "share/dcmtk" CACHE STRING "Installation sub-directory for sample files and the like.")
SET(DCMTK_INSTALL_DOCDIR "share/doc/dcmtk" CACHE STRING "Installation sub-directory for general documentation.")
SET(DCMTK_INSTALL_HTMDIR "share/doc/dcmtk/html" CACHE STRING "Installation sub-directory for HTML documentation.")
SET(DCMTK_INSTALL_MANDIR "share/man" CACHE STRING "Installation sub-directory for man pages.")
Re: CMake: Counterpart to configure option --sysconfdir miss
The question whether the variable should optionally be renamed certainly isn't a crucial feature and a decision up to you devs.
That said the Windows argument stated in the previous comment seems a bit odd.
I figure to most "Windows users" string SYSCONFDIR will be more intuitive and meaningful than ETCDIR.
That said the Windows argument stated in the previous comment seems a bit odd.
I figure to most "Windows users" string SYSCONFDIR will be more intuitive and meaningful than ETCDIR.
-
- DCMTK Developer
- Posts: 2517
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: CMake: Counterpart to configure option --sysconfdir miss
... and a typical Windows user will also never change the defaults (especially not advanced CMake variables, which are hidden by default)
Re: CMake: Counterpart to configure option --sysconfdir miss
This pretty much counteracts your own argument why those GNU variables should be avoided.J. Riesmeier wrote: ... and a typical Windows user will also never change the defaults (especially not advanced CMake variables, which are hidden by default)
-
- DCMTK Developer
- Posts: 2055
- Joined: Fri, 2004-11-05, 13:47
- Location: Oldenburg, Germany
- Contact:
Re: CMake: Counterpart to configure option --sysconfdir miss
Hi,
just to come back to one of the points you made that Jörg did not comment on:
I think the /usr/local thing is not standardized but more an informal convention so far.
Best,
Michael
just to come back to one of the points you made that Jörg did not comment on:
Hm, my experience is that 95% of the software source code packages I download and build on my system want to install themselves into /usr/local. I remember that some big ones (OpenOffice?) used /opt/ but haven't seen that for some time now. Do you have any examples? I agree that Debian and all others quoted put their own version of DCMTK (and most of their built-in other packages) into /usr/bin, /usr/lib and so on. However, DCMTK's default behaviour is meant for those who download DCMTK from the Internet to install their own copy in their Unix system, *not* for the package maintainers.pmattern wrote:I respectfully disagree.not sure whether setting the installation prefix to /usr is often done by people that build DCMTK. I assume that it is more common to install DCMTK to /usr/local
Rather, DCMTK is meant to be used as a regular system library most of the time and as such installed to /usr/lib or variants like /usr/lib<architecture> but hardly ever to /usr/local/. Arch Linux, Debian, Fedora and openSUSE all are dealing with DCMTK that way.
I think the /usr/local thing is not standardized but more an informal convention so far.
Best,
Michael
-
- OFFIS DICOM Team
- Posts: 318
- Joined: Mon, 2014-03-03, 09:51
- Location: Oldenburg, Germany
Re: CMake: Counterpart to configure option --sysconfdir miss
I practically never install software by hand ignoring the package manager, that always seemed like a debian thing to me, as a workaround for their outdated packages. Still, I would prefer that manually installed software would not mix with the native packages, therefore, defaulting to /usr/local seems reasonable. However, we should of course allow to install it to /usr instead (package maintainers could of course find workarounds if we won't, but this would be stupid) and we do, so, we are practically okay as it is. However, I agree that DCMTK_INSTALL_ETCDIR is not an easy find (as I myself wasn't aware) nor is it self explanatory if it is working differently than the "standard approach" SYSCONFDIR. I would therefore vote for renaming it or at least providing DCMTK_INSTALL_SYSCONFDIR as some kind of alias that overrides DCMTK_INSTALL_ETCDIR if it is set.Michael Onken wrote:Hm, my experience is that 95% of the software source code packages I download and build on my system want to install themselves into /usr/local.
Who is online
Users browsing this forum: Bing [Bot] and 0 guests