Is it possible to move the OPAM root? Or, to create a "portable" (in the sense of e.g. "firefox portable") version of an OPAM root?
That is, install a bunch of packages via opam --root=/PATH/TO/A, then move /PATH/TO/A to /ANOTHER/PATH/TO/B, and run everything from there.
A naive try led to a small error in "opam config env", where the old path slipped through. Also, some config files (findlib, global-config) had to be adjusted. After fixing that, some stuff worked, but "utop" fails with
Fatal error: exception Not_found
Is this a principle issue, or is a portable OPAM root just a matter of setting the right environment variables after the move?
Compiler itself is almost portable, a matter of setting environment variables OCAMLLIB and CAML_LD_LIBRARY_PATH, the remaining problem is running bytecode executables which embed path to ocamlrun, see https://caml.inria.fr/mantis/view.php?id=5950 for details.
As for the packages - there is no universal guarantee, it all depends on what package does during the build. Majority of "normal" libraries that don't expect to find some data files at run time should work though. As comments above suggest, it is often faster to take snapshot of opam state (bundle) and rebuild in different path.
Related
My system ocaml instalation also includes the /usr/bin/ocamlbrowser executable. Is there a way I can use it to browse packages I installed with opam?
So far the closest I could get was using the -I flag to add extra directories to the search but I don't know how to tell it to search all folders (the -I flag only adds one at a time) and I don't know how to access the source code for the functions (ocamlbrowser is only finding the mli files, not the ml)
ocamlbrowser -I ~/.opam/system/lib/core -I ~/.opam/system/lib/fieldslib
OCamlBrowser is rather legacy and you need manually specify all the include directories.
For code browsing, ~/.opam/<switch>/lib/* dirs are not sufficient since they usually lack source codes (.ml and .mli's).
You should use the build directories, ~/.opam/<switch/build/packagename/... instead, keeping the source code of the installed OPAM packages. You need to set OPAMKEEPBUILDDIR env var or opam install --keep-build-dir for it.
AFAIK, currently (2014/09) we have no alternatives which is 100% compatible with OCamlBrowser which work fully with OPAM/OCamlFind eco system, but we have ocp-index, ocp-browser and http://ocamloscope.herokuapp.com/ . However, things are rapidly evolving around OPAM and newer tools may be released.
Build systems frequently have separate build and install steps. Sometimes, installed versions will have headers that are older installed on the operating system and those headers may be picked up instead of the headers in the source code. This can lead to very subtle and strange behavior in the source code that is difficult to diagnose because the code looks like it does one thing and the binary does another.
In particular, my group uses CMake and C++, but this question is also more broadly relevant.
Are there good techniques to prevent old headers from being picked up in a build?
1. Uninstall
Uninstall package from CMAKE_INSTALL_PREFIX while hacking develop version.
Pros: very effective
Cons: not flexible
2. Custom install location
Use custom location for installed target, don't add custom install prefix to build.
Pros: very flexible
Cons: if every package use this technique tons of -I option passed to
compiler and tons of <PACKAGE>_ROOT to cmake configure step.
3. Include priority
Use headers search priority. See include_directories command and
AFTER/BEFORE suboptions.
Pros: flexible enough
Cons: sometimes it's not a trivial task if you have a lot of find_package/add_subdirectory
commands, error-prone, errors not detected by autotesting.
BTW
Conflicts can occur not only between build/install directories, but also
in install directory itself. For example version 1.0 install: A.hpp and B.hpp,
version 2.0 install: A.hpp. If you sequentially install 1.0 and 2.0 targets
some #include<B.hpp> errors will not be detected locally. This kind of error can be easily
detected by autotesting (clean environment of CI server don't have old B.hpp file from 1.0 version). Uninstall command also can be helpfull.
Guys recently had fixed the exact same problem with shogun package. You basically need to have your source folders including your header files passed by -I to gcc before the system folders. You don't have to pass the system folders as -I to gcc anyway.
Have a look at the search path here. You might need to have a proper way of including your header files in your source code.
This is the pull request which fixed the problem I guess.
I originally installed boost per the instructions at http://www.boost.org/doc/libs/1_55_0/doc/html/bbv2/installation.html
I transferred most of my Windows user profile to a new computer, which contained a folder called CodeLibs. This folder is where I originally installed boost (in place of PREFIX in above documentation).
I compiled a project that uses the serialization library, and I didn't receive any errors.
My question is, is there any reason to go through the documented installation process again or is the above directory transfer sufficient?
Thanks in advance.
Copying should be fine, so long as the target architecture is the same.
Boost doesn't need to be "installed" in the typical way. There are no registry settigs to set, no COM servers to install, no daemons to set up. Nothing like that.
The install process you went through originally mostly consisted of compiling code. That code, once compiled, was then copied to some destination folder and some environment variables might have been updated.
None of this is truly necessary, but once you get the code on your target machine you might have to tweak a few paths etc so that the compiler can find the headers and libs (if any libs are needed), and executables can find the shared libraries.
Assuming you have a high level of proficiency with such things -- as is suggested by the fact that you were able to install it the first time at all -- I'm sure none of this will be a major challenge for you.
I am new to C++ and I have to handle large integers, so I have to install GMP through Cygwin.
Any documentation I can find on installing this already assumes that you know what you are talking about, and I really don't.
Anyway, I got the right .tar or whatever, extracted it properly, and now any website I see says to run ./configure --prefix=${gmp_install}...
What in the world is gmp_install? And what directory do I run configure from? Huh? I can run it from my little Cygwin terminal, but it just says no such file.
Next, I am supposed to type make. From where?
Help...
Welcome to StackOverflow (SO).
The source directory of GMP should probably contain the file called configure. This is the script which you have to execute to "configure" the build system in your environment. It means that during configuration Autotools (the build system which is used to build GMP) will gather information about your environment and generate the appropriate makefile. Gathering information includes things like: understanding that you are on Windows, understanding that you are using Cygwin, understanding that your compiler is GCC and its version is x.y.z, and etc. All these steps are important for successful build.
You can specify a lot of different options to this configure script to tweak the configuration process. In your case, you specify the prefix option which determines the installation directory, i.e. the directory where you want the built and ready-to-use GMP distribution to reside. For example:
./configure --prefix=/D/Libraries/GMP
will configure the build system to install the GMP binaries to D:\Libraries\GMP directory.
Assuming that the GMP source directory (the one you extracted from *.tar) is located at say D:\Users\Me\Downloads\GMP, in order to build and install GMP you should do the following:
cd /D/Users/Me/Downloads/GMP
./configure --prefix=/D/Libraries/GMP
make
make install
NOTE: The make command will actually execute the makefile (which was generated by configure script) I've mentioned earlier. This file describes the process of building and installing GMP on your system.
NOTE: ${gmp_install} is nothing, but an environment variable. For instance, you could do:
export gmp_install=/D/Libraries/GMP
./configure --prefix=${gmp_install}
this can be useful, for example, when you have to use the same path in multiple places, and don't want to type it everytime. There are other cases, when this is useful, but for that you'll have to learn more about environment variables, what they are for, and Bash scripting in general. However, all this goes far beyond the answer on your question.
You'll have to spend quite some time to understand all these things and how they fit together, and you'd probably have to ask more questions here on SO as understanding all that stuff for a beginner alone might be very challenging.
I have access to computer in a public library and I want to try out some C++ and maybe other code. Problem is that there is no g++ installed and I can't install it using packages because I have no root access. Is there a "smart" way to make a full environment for programming in a home folder?
I have gcc installed (I can compile C code). Also, I have a home folder that is consistent. I don't know where to find precompiled g++, I found only source but I don't know what to do with it. I tried to ask them to install this but it didn't work :)
If you want to install it as a local user
GNU GSRC provides an easy way to do so
Link: http://www.gnu.org/software/gsrc/
After configuration, simply specify the following commands:
cd gsrc
make -C pkg/gnu/gcc
make -C pkg/gnu/gcc install
The second step could also be changed to speed up for an N-core system:
make -C pkg/gnu/gcc MAKE_ARGS_PARALLEL="-jN"
You can run the configure script with the --prefix parameter: ../gcc-4.5.0/configure --prefix=/home/foo/bar. Since it is very likely that the c++ standard library is different then the one on your system, you have to set export LD_LIBRARY_PATH=/home/foo/bar/lib before you can start a program compiled by this compiler.
Once, a long time ago (1992 or so), I went through something similar to this when I bought a SCO system with no development environment. Bootstrapping it up to having a full development environment was a gigantic pain, and not at all easy. Having library header files or gcc on a system would make your job a whole lot easier.
It depends a lot on just how obnoxious the library has been about what kinds of things are installed. If there is no gcc there, your job becomes a bit harder. If there are no header files for glibc there, your job is a LOT harder.
Also, do you get an account on the system so you have a home folder that's consistent from login to login?
If you have no gcc there, you need to find a pre-compiled binary of gcc/g++ and install it somewhere. If you have no header files there, you need to find copies of those and put them on the system.
There is no 'standard' way of installing gcc in your home folder though. All of the solutions are going to have some manner of hand-rolling involved.
Have you asked the librarians if they can change what's installed because you want to learn a bit of programming and only have access to their computers to do it with? That might well be the easiest solution.
From your comment it seems that you do have gcc and if you can compile C code, you have the library header files. So now it's a matter of actually compiling your own version of g++. You could probably find a way to entice the package manager on the system into installing a binary package somewhere other than in a system folder. I think this solution is less fun than compiling your own, and I think there may also be possible subtle problems as that installed package may be expecting to find things in particular places and not finding them there.
First thing to do is to make sure you've downloaded the right source for the gcc package. The place to find that is the GNU United States mirror page. You want to find the gcc-4.5.0.tar.bz2 or gcc-4.5.0.tar.gz file on the mirror site you choose. It will likely be in a gcc directory, and a gcc-4.5.0 sub-folder.
After you have that downloaded, you should untar it. In general you shouldn't build gcc in the folder you untar it into. So create another sibling folder that you actually want to build it in labeled gcc-build. Then the command you want is ../gcc-4.5.0/configure --prefix=$HOME/.local --enable-languages='c c++'.
gcc does require some other packages be installed in order to be able to compile itself. You can use the same --prefix line for these packages to install them in the same place. The gcc website has a list of pre-requisite packages.
$HOME/.local is sort of the standard accepted place for per-user installs of things.
If you have fakeroot, you can use that to set ~/some-path as root to install the packages from. Alternatively, you can setup a chroot environment to do the same.
Given this, you can then use dpkg -i package.deb to install the gcc package(s) on your system. You will need to download and install each package individually (e.g. from the debian website) -- at least binutils, glibc, linux-headers and gcc.
If you are on another system, you will need to get the right packages for that system and install them using the corresponding package manager.