I'm using sandboxes all the time when building Haskell programs and libraries. But occasionally, I build a program that I would like to install system wide. There doesn't seem to be an easy way of taking a program which is built in a sandbox and installing it outside of the sandbox.
Linking Idris to a PATH-folder
If you are on linux it's as simple as putting a symbolic link somewhere into your path - I have a ~/bin for that. So it's the same as bheklilr mentioned only that I usually get the dev-version from github:
git clone git://github.com/idris-lang/Idris-dev idris
cd idris
cabal sandbox init
cabal update
cabal install --dependencies only
make
after this I go to ~/bin and use ln -s [path to idris]/.cabal-sandbox/bin/idris - you can link the other executables too if you like but this one will should be enough to play with idris
If the binary is statically linked (which is true in most cases) then you can do the following
> mkdir tools
> cd tools
> cabal sandbox init
> cabal install tool1 tool2
# Wait a long time
> cp .cabal-sandbox/bin/tool1 ~/.cabal/bin
> cp .cabal-sandbox/bin/tool2 ~/.cabal/bin
On windows you'll have to do
> cp .cabal-sandbox\bin\tool1.exe %APPDATA%\Roaming\cabal\bin
> cp .cabal-sandbox\bin\tool2.exe %APPDATA%\Roaming\cabal\bin
Obviously you should have your user cabal directory on your path.
Your mileage may vary, it's dependent on the executable being built, so for some it might be more difficult to do this sort of thing. In my experience this works pretty well, though. I use it for ghc-mod, hlint, pointfree, and others.
Related
I downloaded automake-1.14 by following this tutorial on Ubuntu 16.04
./configure passed without any error. But the moment I ran make it gave an error.
I actually removed automake-1.15 from linux because when I was
installing protobuf 2.6.1 it says that i can't find automake-1.14. Therefore I remove automake by apt-get autoremove automake. And ran the following commands
$ wget http://ftp.gnu.org/gnu/automake/automake-1.14.tar.gz
$ tar xvzf automake-1.14.tar.gz
$ cd automake-1.14
$ ./configure
$ make # FAIL HERE
$ sudo make install
The Error is the following:
anybody#anywhere:~/anyshare/automake-1.14$ make
GEN t/testsuite-part.am
GEN m4/amversion.m4
CDPATH="${ZSH_VERSION+.}:" && cd . && "/home/anybody/anyshare/automake-1.14/t/wrap/aclocal-1.14"
Can't locate /home/anybody/anyshare/automake-1.14/bin/aclocal in #INC (#INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.22.1 /usr/local/share/perl/5.22.1 /usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base .) at /home/anybody/anyshare/automake-1.14/t/wrap/aclocal-1.14 line 29.
Makefile:2494: recipe for target 'aclocal.m4' failed
make: *** [aclocal.m4] Error 2
Apparently, the original problem -- and likely the problem building Automake -- was an incorrect appearance that the packages' Autotools-based build systems were out of date.
Generally speaking, Autotools-based packages should be distributed with the Autotools outputs pre-built, even though technically, they are derived files. This avoids any need for the Autotools themselves to be installed on the build system for people who are just building the package on a supported system, not modifying or porting it. Distribution packages built by an Autotools-based build system via make dist will in fact include them.
By default and typically, Autotools-based build systems include rules for rebuilding the build system itself if it is out of date. This is a convenience for package maintainers. Autoconf has a built-in mechanism to provide an option for disabling those rules (so-called "maintainer mode") at configuration time, though not all packages make use of it.
Normal operation of tar preserves file timestamps, but if your particular tar fails to do so, whether in general or in your particular case, or if your filesystem's timestamps have poor resolution, then unpacking the source tarballs may produce a result in which the Autotools outputs appear to be out of date. In that case, unless suppressed, the rules for rebuilding the build system will be triggered when you run make.
If this happens to you, and the package's configure script supports the maintainer-mode option, then you can suppress the build-system rebuilding rules by including the --disable-maintainer-mode option when you configure the package. Hindsight being 20/20, I can confidently state that this solves the Protobuf-building problem for you.
I've got a Haxe Application that I want to make available to people with a Windows system. I use Hashlink to run the Application locally and it works very nicely.
I am wondering if I'm supposed to distribute my Application with Hashlink. Can it build me an .exe?
It looks like generating distributable binary files isn't supported out of the box today (March 10, 2017):
> haxe -main Main -hl main.c
Code generated in main.c automatic native compilation not yet implemented
Hopefully it will be supported soon!
Note: I'm talking about building a final executable using hashlink. An entirely separate approach I do not cover here is the possibility of delivering the hashlink virtual machine with your output hl bitcode.
Sane people stop reading here.
But in the meantime... it is possible to generate binaries with hashlink today if you build hashlink from source.
Warnings:
This isn't a generic, cross-platform answer to your question -- it's just my experience on Linux.
There will probably soon be a better way than this.
But I wanted to jot these notes down even for myself to recall later.
Here's what I had to do on Ubuntu 14.04, 64-bit:
Install prerequisite libraries for building hl (there may be others I already have installed, like build-essential, etc)
sudo apt-get install libvorbis-dev libturbojpeg libsdl2-dev libopenal-dev libssl-dev
Clone and build the mbedtls library: (rev note: b5ba28)
cd ~/dev/
git clone https://github.com/ARMmbed/mbedtls.git
cd mbedtls
make CFLAGS='-fPIC'
Clone the hashlink repo: (rev note: eaa92b)
cd ~/dev/
git clone https://github.com/HaxeFoundation/hashlink.git
cd hashlink
In the # Linux section of the Makefile, ~line 67, add these flags:
CFLAGS += -I ../mbedtls/include
LIBFLAGS += -L../mbedtls/library
Now build with make
If everything works, you'll see two important output files, hl and libhl.so
Ok, at this point, it's easiest if you just build your project in the hashlink directory. For example:
# Still in the hashlink directory
haxe -cp /path/to/my/project -debug -main Main.hx -hl src/_main.c
Now run make hlc, and if everything works, hlc is the output executable (which depends on libhl.so):
cp libhl.so hlc /tmp/
cd /tmp/
./hlc
Prints:
Main.hx:7: Hello world!
I am compiling a theorem prover on cygwin and I get this error:
$ make
ocamlmklib -o bin/minisatinterface minisat/core/Solver.o minisat/simp/SimpSolver
.o bin/Ointerface.o -lstdc++
** Fatal error: Error while reading minisat/core/Solver.o: Sys_error("Invalid ar
gument")
Makefile:49: recipe for target `bin/libminisatinterface.a' failed
make: *** [bin/libminisatinterface.a] Error 2
It is not clear what kind of invalid argument is here?
The only documentation I have found for ocamlmklib did not help on understanding the error message. Could it not read the file itself or there is a problem with the contents? ls does list the file:
$ ls -l minisat/core/Solver.o
-rw-r--r-- 1 gbuday mkpasswd 2096 jan. 22 10.42 minisat/core/Solver.o
update: if I remove Solver.o I get a different error message:
** Fatal error: Cannot find file "minisat/core/Solver.o"
So the above error message is about the contents of the object file.
I happen to know that this specifically has to do with the build of the ATP Satallax, which can be used with Isabelle Sledgehammer, and I was asked to look at this.
I have no expertise with make files and ocaml. My success at building Satallax v2.7 came purely from following the instruction in INSTALL, with some minimal ability at guessing at what error codes meant, which I mainly needed when building Satallax v2.6 over a year ago.
The first important thing to do is make sure that the tar file is unzipped while working in a Cygwin terminal, rather than under Windows with something like WinZip.
Assuming that you're working in a Cygwin terminal, these are the notes which I made. After that I'll include text from the Satallax INSTALL, and few comments.
Sources: http://www.ps.uni-saarland.de/~cebrown/satallax/
0) tar xvzf satallax-2.7.tar.gz
1) Cygwin Package (these are also for other's like Leo-II):
zlib-devel, make, OCaml devel, gcc devel, g++ devel, libstdc++6-devel
Ubuntu 12 Packages:
sudo apt-get install build-essential
zlibg-dev using the Ubuntu Software Center
ocaml and g++ if they don't come with "build-essential"
2) Put eprover.exe in the path so that ./configure can find it.
a) There are the following lines in the configure files, which shows
that it's configured to find picomus, eprover has to be in the path
or `which eprover` has to be edited.
# Optionally set picomus to your picomus executable
picomus=${PWD}/picosat-936/picomus
# Optionally set eprover to your E theorem prover executable
eprover=`which eprover`
3) Follow the instructions in INSTALL.
a) export MROOT=`pwd` takes care of this next note, which I had to do
for v2.6, info I keep in here in case I need it in the future.
b) export MROOT=<minisat-dir>, where you replace "minisat-dir" with the
/cygdrive/e\E_2\binp\isaprove\satallax-2.6\cygwin\minisat
3) OLD v2.6 NOTE: If you get an error, delete the old source and try
untaring the sources again.
My build of v2.7 went through without problems, other than the test giving errors.
With Satallax v2.7, there is now the requirement that the build find the eprover. Note STEP 3 of INSTALL tells you to modify configure, or put eprover.exe in the path before the build. I put it in the path, which for me is
E:\E_2\dev\Isabelle2013-2\contrib\e-1.8\x86-cygwin
The INSTALL file then gives short instructions:
* Short Instructions
cd minisat
export MROOT=`pwd`
cd core
make Solver.o
cd ../simp
make SimpSolver.o
cd ../../picosat-936
./configure
make
cd ..
./configure
make
./test | grep ERROR
After downloading all needed packages, and putting eprover.exe in the path, it built without errors for me other than the test, but the executable works when used by Isabelle Sledgehammer.
STEP 3 of INSTALL talks about providing the location of the picomus executable, but I'm pretty sure that there's not need to do that because picosat-936\picomus.exe gets built in this build.
If you watch the build messages, it'll tell you what it's looking for and what it finds.
For completeness, I include the text from INSTALL, except for the instructions related to what's pertinent for Coq.
There are a number of requirements in order to compile Satallax.
In short, you need make, ocaml, g++ and the zlib header files.
In Debian and derived Linux systems, you can get these from
the build-essential and zlib1g-dev packages. You need
ocamlopt to obtain a standalone executable.
If you're not the administrator of the computer on which you're installing,
you can quote the previous paragraph to the administrator.
* Short Instructions
cd minisat
export MROOT=`pwd`
cd core
make Solver.o
cd ../simp
make SimpSolver.o
cd ../../picosat-936
./configure
make
cd ..
./configure
make
./test | grep ERROR
./bin/satallax.opt is the native code executable to use.
See test for examples of how to use it.
* Long Instructions
STEP 1:
Compile minisat (see minisat/README)
cd minisat
export MROOT=<minisat-dir> (or setenv in cshell)
cd core
make Solver.o
cd ../simp
make SimpSolver.o
cd ../..
STEP 2 (Optional. Only needed to extract proof information for proof terms.) :
Build picosat (including picomus):
cd picosat-936
./configure
make
cd ..
STEP 3:
If desired, edit the configure script to give the location of your picomus
and eprover executables. (If the executables are not found by the configure script,
you will need to give the location of the executables to satallax via the command line
options -P <picomus> -E <eprover> if they are needed.)
Run the configure script for Satallax.
./configure
STEP 4:
make
uses ocamlopt to make a standalone executable
./bin/satallax.opt
and uses ocamlc to make a bytecode executable
./bin/satallax
that depends on ocamlrun
STEP 5:
Test satallax using the examples in the script file:
./test
As long as you don't see a line with the word ERROR, it should be working.
Generally to install a package on a linux-based operating system you use
./configure
make
make install
How does this work? And how do I create a package that can be installed this way?
My application uses the Qt framework and I think I'm aiming for something like "MyPackage.tar.gz"
You can create a debian package from your projects. As I understood you want to create a package intended for distibution so I would suggest creating a debian package from your project. Here is an introduction for Debian Packaging system. In the article they at some point describe how to create a "rules" file which is at the core of the build process. Here is a sample of it that I typically use for my Qt/KDE projects:
#!/usr/bin/make -f
#export DH_VERBOSE=1
# This is the debhelper compatability version to use.
#export DH_COMPAT=3
DESTDIR=$(CURDIR)/debian/project
TR_DIR=$(CURDIR)/debian/project/usr/share/qt4/translations
configure:
qmake project.pro
clean:
dh_testdir
dh_testroot
dh_clean
build: configure
dh_testdir
lrelease translations/project_en.ts
$(MAKE)
install: build
mkdir -p $(TR_DIR)
cp translations/project_en.qm $(TR_DIR)
$(MAKE) INSTALL_ROOT=$(CURDIR)/debian/project install
dh_installdirs
binary-arch: build install
dh_testdir
dh_testroot
dh_installmenu
dh_link
dh_strip
dh_compress
dh_fixperms
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb
This is normally sufficent for small projects.
configure is usually part of GNU build system (autotools), which is not in use in a typical Qt project. qmake is used instead for build file generation and it internally handles most of the tasks configure does for non-qt projects.
The typical build install process for a Qt application is
qmake
make
make install
You could create a simple ./configure script that calls qmake if you need the command names to be identical. You can also use autotools with Qt if you need it, see e.g. Qt Creator Instructions For Autotools
Qt is often used with CMake, which I highly recommend. One notable point is that it likes out-of-source-builds.
Your configure script could be
#!/bin/bash
(mkdir build; cd build; ccmake ..)
and the makefile could be
#!/bin/bash
(cd build; make)
Newer versions of debhelper support qmake. A rules file like,
#!/usr/bin/make -f
%:
dh $# --buildsystem=qmake
Is all that is needed. You need,
bar.file = foo
bar.path = install/dir
INSTALLS += bar
Inside your projects 'pro' or qmake file. qmake will create install targets and the perl file /usr/share/perl5/Debian/Debhelper/Buildsystem/qmake.pm will get called and parse the qmake file. You need to create 'debian/' files, changelog, compat, control, copyright as well the rules file.
I have downloaded ode-0.11.1 and I am able to compile source code by modifying the Makefile provided with the demos, but I can't figure out how to manually compile and link the code I need as a standalone.
I tried probing at the Makefile and substituting the macros manually, as well as running it and checking the output.
Does anyone know how to do this?
OpenDE, or ODE, is configured with GNU autoconf/automake tools.
This means that you need to invoke ./configure before you can build the package.
To see all the options, use:
$ ./configure --help
An invokation to ./configure will often need a target where to install to.
A typical invokation would look like this:
$ ./configure --prefix=$HOME --with-trimesh=opcode
$ make install
This will install OpenDE in your home directory.
If you omit the --prefix argument, the default /usr/local will be used, and you will need root permissions to install.
The example invokation will also include support for triangle meshes using OPCODE.