Let's say I install hdf5 as:
$brew install hdf5 --build-from-source --with-mpi
Then I want to build hdf5 without open-mpi as:
$brew install hdf5 --build-from-source
How should I install and switch between both variants?
Should I write a different formula for hdf5-parallel?
You can’t have multiple variants of the same formula with the same version installed at the same time. You need to either create another formula or try to copy the HDF5 directory somewhere else before rebuilding it but it’s hacky and might not work correctly.
Related
I have an R file, but it has packages which are not installed on my R installation. Is there a utility which determines these dependencies from the R file and installs all of them? I don't want to manually install them one by one.
The pacman package offers an efficient way to install / load packages in a single line.
You can refer to this article.
I'm not aware of a way that installs packages completely automatically, as there might be namespace overlap between functions, etc...
We have established a simple local CRAN-like repository for R packages. There are many users, all of which use the same version of Linux.
Is there a way of convincing R to provide pre-compiled Linux packages instead just source ones? The compilation step takes a considerable amount of time for anyone using our repository. It should be possible to precompile and reuse the same binaries, since we can guarantee that the Linux version is consistent for all users.
How could one hack something like this together?
In the very narrow sense of "all of which use the same version of Linux" you actually have an option (that happens to be relatively littler known). Create binary packages using e.g.
R CMD INSTALL --build nameOfDirectoryWithSources
As R CMD INSTALL --help says it
--build build binaries of the installed package(s)
and these are not .deb or .rpm alike packages: no dependency information or alike is added. But they do exactly what you ask for: save on compilation time.
I am not aware of a repository structure one can build of this though.
I have found an old R package with a .zip extension on my PC.
I would like to run it, but I do not have the tar.gz that was used to
create it and I use linux. What are my options?
Few, essentially.
A .zip package for R is almost surely a binary built for Windows so you need to find a suitable Windows computer -- or emulator -- to use it.
So, this can be done this way:
install wine (wine is not an emulator),
install R for Windows, which you download manually from CRAN
install the zip package using the usual commands (install.packages("filename.zip",source=NULL)). You will probably get error messages for the dependencies, but incrementally installing those, it should work.
have a problem with adding new language to cygwin.
As source for language i tried using ubuntu dictionary files.
It would be interesting if anyone could install any non default languages in cygwin spell checker.
The Ubuntu packages use different directories (/usr/lib/aspell vs. /usr/lib/aspell-0.60 on Cygwin), so this isn't going to work. Instead, I suggest you build and install these from the source in one of the following ways:
Download the latest source tarball for your language from http://ftpmirror.gnu.org/aspell/dict/, unpack the tarball, then run ./configure, make, and make install.
Use cygport to build a package for you, then manually install it. For example, create an aspell-lt.cygport file with the following contents:
ASPELL_COMPAT=6
inherit aspell-dict
NAME="aspell-lt"
VERSION=1.2.1.0
RELEASE=1
CATEGORY="Text"
SUMMARY="Aspell Lithuanian dictionaries"
Then run cygport aspell-lt.cygport fetch prep build install package. Such a package would then be fit for contribution to the Cygwin distribution.
I am developing a framework for reproducible computing with R. One problem that I am struggling with is that some R code might run perfectly in version X.Y-Z of a package, but then why you try to reproduce it 3 years later, the packages have updated, some functions are changed, and the code doesn't run anymore. This problem affects also for example Sweave documents that use packages.
The only way to confidently reproduce the results is by installing the R version and version of the packages that were used by the original author. If this was a single case, one could pull stuff from the CRAN archives and install appropriate versions. But for my framework this is impractical, and I need to have the package versions preinstalled.
Assume for now that I restrict myself to a single version of R, e.g. 2.14. What would be a practical way to install many versions of R packages, so that I can load them on the fly? I suppose I can do something like creating separate library directories for every version of every package and then using custom lib.loc arguments while loading them. This is going to be messy though. Any tips or previous attempts to do something similar?
My framework runs on Ubuntu server.
You could install packages with versions (e.g. rename to foo_1.0 directory instead of foo) and softlink the versions you want to re-create a given R + packages snapshot into one library. Obviously, the packages could actually live in a separate tree, so you could have library.projectX/foo -> library.all/foo/1.0.
The operating system gives you even more handles for complete separation, and the Debian / Ubuntu stack as a ton of those available. Two I have played with are
chroot environments: We use this to complete separate build environments from host machines. For example, all Debian uploads I produced are built in a i386 pbuilder chroot hosted on my amd64 Ubuntu server. Chroot is a very powerful Unix system call. Chroots, and particularly the pbuilder system built on top of it (for Debian package building) are meant to operate headless.
Virtual machines: This gives you full generality. My not-so-powerful box easily handles three virtual machines: Debian i386, Ubuntu i386 as well as Windoze XP. For this, I currently use KVM along with libvirt; this is Linux specific. I have also used VirtualBox and VMware in the past.
I would try to modify the DESCRIPTION file, and change the field "Package" there by adding the version number.
For example, you download the package source a from CRAN page (http://cran.r-project.org/web/packages/pls/). Unpack the compressed file (pls_2.3-0.zip) to a directory ("pls/"). The following steps are to change the package name in DESCRIPTION ("pls/DESCRIPTION") and installation with R command 'R CMD INSTALL pls/', where 'pls/' is a path to the package source with modified DESCRIPTION file.
Playing with R library paths seems a dangerous thing to me.