DICOM @ OFFIS

Discussion Forum for OFFIS DICOM Tools - For registration, send email with desired user name to the OFFIS DICOM team
It is currently Tue, 2018-01-16, 20:26

All times are UTC + 1 hour




Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue, 2016-11-08, 23:26 
Offline

Joined: Tue, 2016-11-08, 13:18
Posts: 18
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.


Top
 Profile  
 
PostPosted: Wed, 2016-11-09, 11:27 
Offline
DCMTK Developer

Joined: Fri, 2004-11-05, 13:47
Posts: 1661
Location: Oldenburg, Germany
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


Top
 Profile  
 
PostPosted: Wed, 2016-11-09, 12:11 
Offline
DCMTK Developer

Joined: Fri, 2004-11-05, 13:47
Posts: 1661
Location: Oldenburg, Germany
P.S: Does CMake option DCMTK_INSTALL_ETCDIR the trick?


Top
 Profile  
 
PostPosted: Thu, 2016-11-10, 14:24 
Offline

Joined: Tue, 2016-11-08, 13:18
Posts: 18
Quote:
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
I respectfully disagree.
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.

Quote:
P.S: Does CMake option DCMTK_INSTALL_ETCDIR the trick?
Basically it does, yes. Two remarks:
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:
option(VTK_ENABLE_KITS "Build VTK using kits instead of modules." OFF)
of VTK. In 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. Would it be feasible to have something like that in DCMTK as well?


Top
 Profile  
 
PostPosted: Thu, 2016-11-10, 18:22 
Offline
DCMTK Developer

Joined: Tue, 2011-05-03, 14:38
Posts: 1889
Location: Oldenburg, Germany
Only answering to a certain aspect of your posting (I guess that Michael will answer to the others):

Quote:
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.

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.

Quote:
In 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.

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 Autoconf :wink:

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.


Top
 Profile  
 
PostPosted: Fri, 2016-11-11, 13:37 
Offline

Joined: Tue, 2016-11-08, 13:18
Posts: 18
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.


Top
 Profile  
 
PostPosted: Fri, 2016-11-11, 14:02 
Offline
OFFIS DICOM Team
OFFIS DICOM Team

Joined: Mon, 2014-03-03, 09:51
Posts: 228
Location: Oldenburg, Germany
Do you by chance know what other CMake based projects use as the name for such a variable?


Top
 Profile  
 
PostPosted: Fri, 2016-11-11, 15:07 
Offline

Joined: Tue, 2016-11-08, 13:18
Posts: 18
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.


Top
 Profile  
 
PostPosted: Fri, 2016-11-11, 16:05 
Offline
OFFIS DICOM Team
OFFIS DICOM Team

Joined: Mon, 2014-03-03, 09:51
Posts: 228
Location: Oldenburg, Germany
pmattern wrote:
Grepping through the Arch Linux PKGBUILDS suggests SYSCONFDIR, <software>_INSTALL_SYSCONFDIR and CMAKE_INSTALL_SYSCONFDIR are rather commonly used.

Great, is anybody against introducing these variables then, replacing DCMTK_INSTALL_ETCDIR?

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.
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.


Top
 Profile  
 
PostPosted: Fri, 2016-11-11, 17:17 
Offline
DCMTK Developer

Joined: Tue, 2011-05-03, 14:38
Posts: 1889
Location: Oldenburg, Germany
Quote:
Great, is anybody against introducing these variables then, replacing DCMTK_INSTALL_ETCDIR?

As I wrote earlier (see above), I don't see any advantage in renaming the variables. So, I would vote against it.

Also please note that there is a reason for the current naming scheme. The following excerpt is from "CMake/dcmtkPrepare.cmake":
Code:
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.")

Finally, the system of "GNU standard installation directories" is certainly a nice thing but what about non-GNU platforms like e.g. Windows? I don't think that a Windows user will actually understand all this...


Top
 Profile  
 
PostPosted: Fri, 2016-11-11, 17:57 
Offline

Joined: Tue, 2016-11-08, 13:18
Posts: 18
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.


Top
 Profile  
 
PostPosted: Fri, 2016-11-11, 18:03 
Offline
DCMTK Developer

Joined: Tue, 2011-05-03, 14:38
Posts: 1889
Location: Oldenburg, Germany
... and a typical Windows user will also never change the defaults (especially not advanced CMake variables, which are hidden by default) :wink:


Top
 Profile  
 
PostPosted: Fri, 2016-11-11, 18:58 
Offline

Joined: Tue, 2016-11-08, 13:18
Posts: 18
J. Riesmeier wrote:
... and a typical Windows user will also never change the defaults (especially not advanced CMake variables, which are hidden by default)
This pretty much counteracts your own argument why those GNU variables should be avoided.


Top
 Profile  
 
PostPosted: Sat, 2016-11-12, 16:30 
Offline
DCMTK Developer

Joined: Fri, 2004-11-05, 13:47
Posts: 1661
Location: Oldenburg, Germany
Hi,

just to come back to one of the points you made that Jörg did not comment on:
pmattern wrote:
Quote:
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
I respectfully disagree.
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.

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.

I think the /usr/local thing is not standardized but more an informal convention so far.

Best,
Michael


Top
 Profile  
 
PostPosted: Mon, 2016-11-14, 09:58 
Offline
OFFIS DICOM Team
OFFIS DICOM Team

Joined: Mon, 2014-03-03, 09:51
Posts: 228
Location: Oldenburg, Germany
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.
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group