0

Is there a way to create install and package (I need a deb package) targets using CMake, where install path is read from some configuration file (e.g. /etc/myconfig.cfg) in install-time. I can do it using shell scripts, but I'd like to use CMake's and CPack's possibilities. I'd like a generated deb package to read myconfig.cfg in install time

A very simple example of start CMakeLists.txt:

cmake_minimum_required(VERSION 2.8.11 FATAL_ERROR)
project("My project")
add_executable(a.out main.cpp)

/etc/myconfig.cfg:

set(INSTALL_PATH "/var/path1")

or:

INSTALL_PATH = /var/path1

or something similar.

Роман Коптев
  • 1,555
  • 1
  • 13
  • 35

2 Answers2

1

Why not use CMAKE_INSTALL_PREFIX? For example:

cmake -DCMAKE_INSTALL_PREFIX=/usr/boob ..
Joel
  • 1,805
  • 1
  • 22
  • 22
  • 1) I must start cmake, not just make, to do so. 2) I don't want the computer, where I install the deb package, would have cmake, gcc and so on dependencies. Only compiled files must be installed. If it is possible to do such deb package with cmake, as I understand, it will use install instructions in cmake script. 3) My real task is more complex and it's difficult to manage all manually. If I understand how to do this simple example, I'll do everything other – Роман Коптев Mar 29 '16 at 15:56
  • 1.- Either way you need to tell cmake how to handle the CONTROL script for the deb package. I understand that you just start cmake, but you can't just jump to what you want or expected to do without some background first. 2.- It doesn't need to, but you need some developer hardcode first to fully automate the process. 3.- Manually is the only way, my friend. I recommend to see the docsand examples about [configure_file](https://cmake.org/cmake/help/v3.0/command/configure_file.html) which more or less and CMAKE_INSTALL_PREFIX will help you on your first steps. – Joel Mar 29 '16 at 16:57
  • I'm developing a fast cgi application. Each new version must be installed in a new location with some files and started while previous version is working. Then configuration of web server changes, previous version must be stopped and deleted. I've asked this question to have ideas how to automate this process. I've done this with shell scripts in not crossplatform way and would like to do all with cmake as I use it to compile the project. But I don't see how to do something with cmake. Very ugly. – Роман Коптев Apr 04 '16 at 13:19
  • @РоманКоптев, if you read the documentation command that I gave you and find examples about them, you should get the idea by now. – Joel Apr 04 '16 at 14:29
  • The only way I've done it was to use `install(CODE|SCRIPT)` and create `add_custom_target(package "${CMAKE_COMMAND}" -D -P)`. I manually combine the packages because CPack in this case generates empty ones. It's very ugly, esp. if smb uses `add_subdirectory` command: the order of `install` commands is not gauranted; it's impossible to create custom target "install". The `CMAKE_INSTALL_PREFIX`, `configure_files` are no use. They'll be executed only once, when cmake is started (& not on the target machine), and then you work with same paths every `make`, `make install`, `make package`. – Роман Коптев Apr 07 '16 at 00:56
0

I realise this question is as old as the hills...

What you're proposing isn't possible with Apt (or RPM, or numerous other package types) - and so cpack can't provide the facilities either.

The reasoning being that the package is supposed to describe the things it will install into the system - and most critically, the things it'll remove if the package is uninstalled, or if a subsequent version of it no longer include files in the older version. You can understand that this wouldn't be possible if a config file could alter the way the package landed on the system because after install the config could change, making the on-going maintenance of files impossible.

What you're asking for is somewhat "non standard" for a package, and somewhat problematic for running systems. Instead, you have a number of options...

  1. Make a package for each installation variant you expect
  2. Make a single package, and then use a post-install Bash script to do all the path creation/adjustments you need
  3. Use a package to "centrally" put files in place, and then use Configuration Management (Ansible, Puppet, Chef etc) to do the remaining work.

Personally, I'd recommend option 3. Option 1 is a lot of work, Option 2 is "messy" in so much as the administrator will be left with a load of files and directories which aren't owned by any package, making uninstall difficult. It also encourages the creation of a handful of Bash scripts which are hard to maintain and most likely won't do what they're supposed to in all the places your package gets deployed.

The Third option leaves the sysadmin in control, and they'll have the knowledge of what's on their system, what to remove if they need to, etc.

Ralph Bolton
  • 774
  • 7
  • 14