The Haskell package optparse-applicative provides instructions for creating a bash completion script for an executable, and then suggests that this
should be shipped with the program and copied to the appropriate directory usually (/etc/bash_completion.d/) during installation.
I wold like to ship and install this script with my package, along wit the executable. How do I instruct Cabal (in my .cabal) to
include the bash completion script along with my package, and
copy the script to /etc/bash_completion.d/?
Related
A few days ago I had a few problems while installing trying to install lapis on my new installation of linux mint. The main problem was that I wanted to have lua 5.3 as the main lua interpreter on my system, but lapis only works with lua 5.1.
This is how I ended up installing it
Note: Instructions for normal installation process, with aditional lua 5.3 being optional
Prerequisites
First of all install all the prerequisites with apt-get install libreadline-dev libncurses5-dev libpcre3-dev libssl-dev perl make build-essential*. This is all you should need to install lua, luarocks and openresty.
* copied from openresty website
Lua Interpreter(s)
Next, go to https://www.lua.org/versions.html and download the latest version of lua5.1 (wget https://www.lua.org/ftp/lua-5.1.5.tar.gz). Then extract the downloaded file tar -xf lua-5.1.5.tar.gz and optionally rename the directory mv lua-5.1.5 lua51.
Now you can simply build and install lua by moving to the directory cd lua51 and running make make linux and sudo make install
Aditionally, you might want to have lua5.3 installed on your system as the main lua interpreter. Luarocks doesn't seem to particularly like this kind of setup though, so I recommend the following:
First download and extract (and optionally rename) both lua5.1 and lua 5.3; go to the lua 5.1 directory and open Makefile in a text editor; Edit lines 12-15 to install lua in another directory. For me it worked to just add /lua51 to INSTALL_TOP (line 12). Next go to line 44 and change the names of the binaries (I chose lua51 and luac51), optionally do the same with the man pages (this requires also changing them in the doc subdirectory).
The next step is to go to the src/ directory and edit the makefile there as well: in lines 32 and 35 change the names as you did in the previous makefile (lua51 and luac51 in my case).
After this you can just make linux and sudo make install as described above.
Luarocks
Now you need to install luarocks on your system. Start by downloading the latest release of luarocks (http://keplerproject.github.io/luarocks/releases/) and extract it. Again, you can rename it to luarocks/ reduce typing. cd to the directory you just extracted and run ./condigure.
If you changed the lua installation path, you will have give some parameters to the configure script:
For lua 5.1 ./configure --lua-version=5.1 --with-lua=/usr/local/lua51 --lua-suffix=51 is how I had to do it (--lua-suffix is what I added to lua and luac and --with-lua tells it where the bin, lib, etc. subdirectories are; only relevant if you changed INSTALL_TOP in the makefile)
Optionally you can now proceed to (download, ) build and install lua 5.3 with its standard configuration. After that you can even go back to the luarocks directory and repeat ./configure, make build and make install and it should automatically install itself with lua 5.3 and leave the installation for lua5.1 intact**.
** the luarocks executable is actually just a symlink to luarocks-VERSION (where VERSION can be 5.1, 5.3, etc.) in the same directory. Each time you install luarocks this link is overwritten to point to the latest installation, but the other executables are still there.
OpenResty
The next step is to install OpenResty: open http://openresty.org/en/installation.html and check the prerequisite section. It should say the same as at the beginning of this answer. If not, install any missing package now. You can also just follow the installation instructions there, but I will be repeating it anyway; go to http://openresty.org/en/download.html and download the latest version. Extract the downloaded archives (and rename the new directory to simply openresty). cd to the new directory and run ./configure --with-pcre-jit --with-ipv6 (this might take a while), make (this might take an even longer while) and sudo make install.
At this point everything except lapis itself should be set up and working.
Lapis
To install lapis, type sudo lurocks install lapis (user luarocks-5.1** instead if you have installed more than one version of it).
Congratulations! If you got no errors, you should now have lapis installed and ready to use :)
** see section Luarocks.
I am trying to include the libjsoncpp package into my Yocto build, which is not currently included in Yocto's package list. I downloaded the source files from http://sourceforge.net/projects/jsoncpp/files/jsoncpp/. The package does not come with an INSTALL script but instead uses scons.py. How can I write the install script for this as a recipe?
Thanks
I downloaded the jsoncpp-src-0.6.0-rc2.tar from that link and didnt see any scons.py, even though the README says it should be there. I did however look through the SConstruct included therein, which is the main SCons build script.
To be able to use it, you will need to (obviously :) ) install Python and SCons, as indicated in the README:
(I would recommend the latest version of SCons, which is 2.3.0, hopefully its compatible)
Building/Testing: =================
JsonCpp uses Scons (http://www.scons.org) as a build system. Scons
requires python to be installed (http://www.python.org).
You download scons-local distribution from the following url:
http://sourceforge.net/projects/scons/files/scons-local/1.2.0/
Unzip it in the directory where you found this README file. scons.py
Should be at the same level as README.
python scons.py platform=PLTFRM [TARGET]
You should then be able to invoke scons from your scripts as follows:
$ scons -f <path to json>/SConstruct platform=linux-gcc
Substitute linux-gcc with your platform. Read through the SConstruct and search for platform to see all the possibilities.
I have a non-Haskell executable (bash script) that I would like cabal to install in ~/.cabal/bin along with my Haskell library. How can I achieve this simply with cabal?
Edit: as I mentioned in a comment below: installing specifically to ~/.cabal/bin isn't crucial, I just need the script to be available in my library.
You can use cabal's data-files field to have some extra files installed, and then use the getDataFileName function created by cabal to retrieve the file. Details are available in the documentation and this blog post.
Some Perl modules, such as DBI, need to be downloaded, compiled and installed.
I'm connecting to a remote production testing computer, for which I have only my local user password (no root, for obvious reasons). I've used wget to download some external modules that I need, such as DBI, and unpacked these resulting in directories like ~/modules/DBI-<version>.
Normally, when compiling something for Linux, you run configure to pre-configure everything before installation; and one of its switches is --prefix=<some_dir>, which controls where the compiled executable and all compiled dependencies will ultimately end up.
But for Perl modules, you don't run configure, so my first question is:
Can I control where the compiled modules (e.g. DBI.pm) go when I run make? If so, how?
Failing that, I at least need to update #INC, so I can refer to the module; so my second question is:
How can I find out where the compiled modules went when I ran make?
I can't issue make install after compiling, and moreover, I've been asked not to. (I've been asked to design the script so that it doesn't rely on external modules being in the standard system path.)
perl modules should either be installed with the distributions's system, like you did with gentoo or pkg_add on BSD, etc. or by using CPAN. Don't do what you're doing, that is going to confuse you & the system.
perl -MCPAN -e "install DBI"
You can use local::lib to install Perl modules in a custom directory. Modules so installed can be used from Perl scripts:
use local::lib '/path/to/custom/directory'; # Custom modules can be `use`d from hereon
cpanm uses local::lib internally when you use the -l or -L flag. To install a module in the current directory:
cpanm -l. DBI
The installation directory is set when the makefile for the module is built. Each module comes with a Makefile.PL which must be run to build the makefile, taking into account the current Perl configuration. Makefile.PL has the option PREFIX that says where the build is going to be installed, so after unpacking the module's distribution and cding to the unpacked directory you can say
perl Makefile.PL PREFIX=/module/directory/path
make test
make install
This process is described in the Perl documentation - read perldoc perlmodinstall. You could go into the CPAN shell and use the 'o' (lower-case) oprion that allows you to change the options passed to makefile.PL, but I think the manual build/test/install is more straightforward and gives you more control over the process.
Remember to add
use lib qw(/module/directory/path);
to the start of your program to make sure Perl searches the new directory for modules.
I've stumbled on a make file "Makefile.am" and I tried to use "make -f Makefile.am" on it to no avail. What am I doing wrong?
It's an automake script/makefile. You can learn everything about automake, autoconf, libtool and such through the called autobook.
Basically, the steps would be to run automake, then autoconf, then configure, then make to build the software you have. These steps are neccessary to build the configure script, that automatically search for needed libraries and such on your system.
The process is not easy, unless your software also includes an already generated "configure" file. If so, the only thing you have to do (mostly) is to just run ./configure, then make, then make install to install the software to a default location. If you want to change configure options, you can also look at ./configure --help.
You stumbled upon an automake file, which is used to create a Makefile from the source, in this case Makefile.am.
From http://developer.gnome.org/doc/GGAD/z70.html, they explain it as:
automake processes Makefile.am to produce a standards-compliant Makefile.in. automake does a lot of work for you: it keeps up with dependencies between source files, for example. It creates all the standard targets, such as install and clean. It also creates more complex targets: simply typing make dist creates a standard .tar.gz file if your Makefile.am is correct.
Basically, you should run 'automake' to make the Makefile, and you will probably run into the same situation with the configure script with 'autoconf'.
Automake: http://www.gnu.org/software/automake/
Wikipedia article on automake: http://en.wikipedia.org/wiki/Automake
If you are trying to compile a 3rd party application from source, there is usually a 'configure' script located at the top of the source tree. If you run ./configure --help from that location, you'll get a list of options you can set. Usually, --prefix is the most common to use.
After running the script, you'll get standard Makefile's generated from the automake files. From there, you can just execute make normally.
Standard build steps for linux packages are:
./configure
make
make install
see "man automake" or google for autotools. likely you'll want to run something like autogen.sh first.