I'm creating a Linux tgz self-extracting installer using CPack and I'd like the installer to run a script or sequence of commands after all files have been installed. CPack documentation contains the following guidance:
CPACK_INSTALL_COMMANDS Extra commands to install components.
I set this variable in my CMakeLists.txt file and I see it set in the resulting CPackConfig.cmake file, but the commands I embed in this variable do not appear anywhere in the final .sh install script. What am I missing?
You're not missing anything, that's simply not how the CPACK_INSTALL_COMMANDS variable works.
On a typical project, CPack does a "make install" into a temporary location, in order to build the final installer based on the "make install" tree. The CPACK_INSTALL_COMMANDS variable is meant to be set for projects that would rather run some other command sequence, instead of the typical "make install" in order to produce the install tree.
So, CPack should be running your commands as it generates the package. It will not run your commands on the end user's machine at the end of him/her running the generated installation script...
There are per-generator ways of running installed executables and/or scripts at the end of the end user installation, but it will require some customization on your part. In this case, I'd recommend attempting to override the CPack.STGZ_Header.sh.in input file that is used when CPack generates the STGZ self-extracting script. Customize that file and add your calls to the bottom of it, above the line:
exit 0
To override the file, provide your own copy of it in your source tree, perhaps in a ${CMAKE_CURRENT_SOURCE_DIR}/CMake directory, and then in your CMakeLists.txt file, add:
set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_SOURCE_DIR}/CMake ${CMAKE_MODULE_PATH})
(Actually, as I'm writing this, I'm wondering if that's sufficient, or if the module path also needs to be set at the time that CPack runs... Try this, and let us know if your customization gets used by CPack or not. If not, I'll investigate a bit further and add some more advice here.)
Related
I have cmake target which runs a setup.exe on windows which installs a tool using add_custom_target as follows
# TOOL_TEMP_INSTALL_PATH is the installation path which is set earlier in cmake
add_custom_target(
install_tool
COMMAND ${TOOL_TEMP_DIR}/setup.exe /DIR=${TOOL_TEMP_INSTALL_PATH}
)
After the installation, I want to replace text in a configuration file located at ${TOOL_TEMP_INSTALL_PATH}/tool.ini replacing a line of text "LICENSE_FILE=Enter License server" with "LICENSE_FILE=30309#server"
Following commands will achieve this but this needs to be run after install_tool target is built.
file(READ "${TOOL_TEMP_INSTALL_PATH}/tool.ini" filedata)
string(REGEX REPLACE "LICENSE_FILE=Enter License server here"
"LICENSE_FILE=30309#server" filedata "${filedata}")
file(WRITE "${TOOL_TEMP_INSTALL_PATH}/tool.ini" "${filedata}")
How can I add these commands as a dependency to install_tool? Or is there a better way to achieve this on windows?
Since you want to run two things in order as part of the same target, you can use multiple COMMAND entries in the same target. The difficulty is that COMMAND can't handle CMake code, but only system commands. The typical solution is to call CMake in a subshell on a script file:
COMMAND ${CMAKE_COMMAND} -P path_to_script
So, place your file modification commands in a file in your source tree called license-install.cmake, and add another COMMAND to your add_custom_target
Hint: You might consider add_custom_command instead, so you can specify a file in the installed tree as a dependency. This will allow CMake to see the installed tool as a build product, and to skip the install step if the tool is already installed. You'll still need an add_custom_target with a dependency on your command output to hook it in correctly.
Good morning, I am reading about the prepared scripts in MacOSX to use when creating a pkg for my application.
In particular, I have some doubts how to make sure that postupgrade script is used.
What I read till now is:
from here
The postupgrade script is run after files have been installed and before the postflight script if one is defined. This script is run only if the component has been previously installed. If the script does not return an exit status of zero, Installer will declare the installation has failed.
Ok then it seems that postupgrade will just run in automatic when an upgrade is done. BUT...from man pkgbuild, section --scripts scripts-path
Archive the entire contents of scripts-path as the package scripts. If this directory contains scripts named preinstall and/or postinstall, these will be run as the top-level scripts of the package. If you want to run scripts for specific bundles, you must specify those in a component property list; see more at COMPONENT PROPERTY LIST. Any other files under scripts-path will be used only if the top-level or component-specific scripts invoke them.
So, it seems I should add it to the component.plist, since they do not say anything about postupgrade. BUT it seems strange, I would put there more specific script, not the postupgrade script.
Reading more, I found it that refers to this, where there is written:
To determine whether a Package has already been installed or not, Installer.app is having a look at the content of the following directory: /Library/Receipts. If there's a file named PackageName.pkg within it, then the Package has already been installed, otherwise it's the first install.
Well, my application leaves no pkg file there, but yes it is present in the InstallHistory.plist.
Well, finally the question: should I set the upgrade script somewhere, for example in the component.plist file? The last link seems to be out of date, something has changed? How can I put a pkg file inside /Library/Receipts? Or better, how can be sure if my installation is indeed an installation and not an upgrade, or viceversa?
Thanks everyone, I am a bit confused...
I'm trying to set up haxe development environment. I'd prefer not to install haxe in /usr, so I edited haxe Makefile so that the install directory is a local one:
INSTALL_DIR=/home/liori/Programy/haxe.install
However, now I cannot use haxelib:
% PATH=/home/liori/Programy/haxe.install/bin:$PATH haxelib setup /home/liori/Programy/haxe.install/haxelib
Standard library not found
How to execute haxelib in these circumstances?
Since the error mentioned "Standard library not found", probably the "std" folder is misplaced somehow.
The haxe standard lib folder, "std", should be placed right next to the "haxe" executable. If you want to have an alternative setup, you should set up an env variable, HAXE_STD_PATH, which points to the "std" folder. Try set it up and run haxelib again.
If that still doesn't work, try to open the haxelib executable in a text editor, it should be a script that runs haxe. See if any of the arguments is wrong.
Yet another option is to make haxelib, which will produce a compiled haxelib executable instead of the script based one.
This question has been asked many time but I am not able to resolve the problem from them so I am asking
I had installed Cygwin a few days ago.I tried using ./configure command but it says
-bash: ./configure: No such file or directory
I tried using
where configure
but I got the output
INFO: Could not find files for the given pattern(s).
then I tried grep configureand I got this output
/etc/bash_completion.d/configure
/usr/i686-pc-cygwin/sys-root/usr/share/libtool/libltdl/configure
/usr/share/ELFIO/configure
/usr/share/libtool/libltdl/configure
I tried to export the path and then run the ./configure but it also didn't worked.
I find no executable file named as configure in my cygwin bin directory.
Does it mean that I have to add configure file manually?How can I correct it?
NOTE :- I had also tried sh configure but it also didn't worked
If a software project is set up to be built using autoconf, that tool generates a script canonically called configure. It queries the system for various parameters that are subsequently used in the build, and is specific to the software package to be built. Different software projects have different configure scripts. They are all called configure, but their contents are not the same.
So, to actually build such a software project once that script was set up (usually done by the maintainers when packaging the source tarball for distribution), you call:
tar xzf <tarball>.gz # or xjf <tarball>.bz2 or whatever
cd <sourcedir> # the one you just untarred
./configure
make
make install
Note the prefix ./, which means "located in this directory" (i.e. the top directory of that project's source tree).
Actually, the better procedure is the so-called "out-of-tree build", when you set up a different directory for the binaries to be built in, so the source tree remains unmodified:
tar xzf <tarball>.gz # or xjf <tarball>.bz2 or whatever
mkdir builddir
cd builddir
../<sourcedir>/configure
make
make install
So, there is supposed to be no configure executable in your PATH, you are supposed to call the script of that name from the source tree you are trying to build from.
If I correctly understood...
Configure is not an application that should be installed on your system, but script that should be delivered with source code to prepare for make command. File named configure should be in the main directory of source code.
I understand that this is an old question. However many might find this solution helpful.
Normally we use the make command to compile a downloaded source in cygwin. In many cases it contains a autogen.sh file. Running that file with
bash autogen.sh
will in many case solve the problem. At least it solved my issue and i could then use the make command
I was wondering if the following is possible.
I have a BASH script that I want to make available for some people but I wanted them to only have to "install" the program and not messing around with terminal, so I thought a .deb would be cool.
So what would the "install" do?
Simple. I want to move the script and an icon to a folder (any folder, but I was wondering some hidden folder in Home) and then run a script that creates a launcher in the Applications menu for the first script. It seems there isn't much to it, but for what I've searched, there doesn't seem to be a lot of info...
How can I accomplish this?
By the way, I'm using Ubuntu 11.04.
Basically (install and) run dh-make to set up the debian/ directory, edit the generated files (mainly remove the many you do not need, and fill in a package description and any dependencies in debian/control), then debuild-us -uc -b.
You may also have to set up a simple Makefile for debian/rules to call; it probably only needs an install target to copy the binary to $(DESTDIR)/usr/bin.
Binaries install into /usr/bin and you should not try to override that. The way to have a menu is to add a .desktop file.
Once you have a good .deb you will need to set up a repo for distributing it. The simplest solution is probably to set up a launchpad.net account and create a personal PPA there.
It's not hard to find more information on these topics, but of course, you need to know what to look for. The canonical documentation is the Debian New Maintainer's Guide.
Found this video on youtube that explains IN FULL the process of creating a *.deb for a script or program and even mentions how to do it for a C program.
Full guide in how to build simple *.deb package
Has one bug, btw, that the author, during the making of the *.deb, didn't notice. The path in the *.desktop file for the EXEC parameter is wrong in the example.