While in a conda environment (source activate), how can I make install into the environment library directories (lib, bin, etc.) and not the system directories?
Note that I do NOT want answers related to conda-build.
Use the -C (change directory) argument to tell make to use a different directory:
make -C $CONDA_PREFIX/lib install
From the manual:
-C dir, --directory=dir
Change to directory dir before reading the makefiles or doing anything else.
Related
I'm trying to override a command that currently defaults to the executable in /usr/local/bin/ffmpeg. I thought I could do it by exporting a PATH to ffmpeg installed with homebrew above the one installed in /usr/local/bin, but when I edit ~/.bash_profile I cannot find the exported path /usr/local/bin. Yet, when I echo the PATH I see /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/ with the exported paths appended to it. Any idea how I can override commands in /usr/local/bin?
/home/user/.profile and other things actually included from global /etc/profile.d, /etc/bash.bashrc and so on, depending on your distributive. They are primary for your shell.
There is no defaults, Linux just searching first occurence of executable in your PATH, so just place directories in correct order in PATH:
Instead of:
PATH=$PATH:/mydirectory/bin
Use:
PATH=/mydirectory/bin:$PATH
Every now and then a new tarball or a new xyHub/Lab-repository needs to be built. They usually come with a Makfile or an Autotools/CMake/XY-Generator provides one on the fly. As the maintainers most likely use another operating system or distribution than the one I am currently running, the assumptions that went into their Makefiles usually do not fit my filesystem hierarchy (lib vs. lib64, bin vs. sbin, /usr/lib vs. /lib and so on). As the final command in the build sequence usually is
sudo make install
it is quite annoying to move thousands of files to the correct place. Or even worse determine which files of my distribution were overwritten. Here GNU Makes dry run mode comes in very handy. Running
sudo make -n install
first, saves me the trouble of cleaning up my file system, by just printing all the commands from all active GNU Make recepies without executing them. In case of a handwritten or Autotools-generated Makfile this works as intended. If the Makefile contains something like:
#PREFIX is environment variable, but if it is not set, then set default value
ifeq ($(PREFIX),)
PREFIX := /usr/local
endif
install: unixlib.a
install -d $(DESTDIR)$(PREFIX)/lib/
install -m 644 unixlib.a $(DESTDIR)$(PREFIX)/lib/
install -d $(DESTDIR)$(PREFIX)/include/
install -m 644 unixlib.h $(DESTDIR)$(PREFIX)/include/
I would see exactly what would happen. Every install/cp/mv-command with the full path information would be printed. If I made a mistake with the install prefix in the configure step I can see it there. If the default in the Makefile is weird because it comes from another OS, I would see it there.
Now in case of a CMake-generated Makefile this is different. Doing
mkdir build && cd build
cmake ..
make
sudo make -n install
only produces output that ends in
...
make -f CMakeFiles/Makefile2 preinstall
/usr/bin/cmake -E cmake_echo_color --switch= --cyan "Install the project..."
/usr/bin/cmake -P cmake_install.cmake
As these commands get not executed, just printed, I do not get all the cp/mv/mkdir/install/etc-commands that I would like to see first, before I let the Makefile touch the file system.
Is there a way to get the list of commands that would be executed from the install target in a CMake-generated Makefile as it is the case with handwritten or Autotools-generated ones?
Is there a way to get the list of commands that would be executed from the install target.
Actually, the core part of installation process is contained in the file cmake_install.cmake (which is created in the build directory). This file is processed as CMake script using cmake -P flow of the cmake executable.
The script cmake_install.cmake performes installation of files with install command. Semantic of the install command, used by the script, differs from the one described in documentation: internally, CMake uses some undocumented features of the command.
But it shouldn't be so hard to understand cmake_install.cmake script in general and deduce paths from it.
I just installed CD-HIT and followed these instructions:
Installation
Most CD-HIT programs were written in C++. Installing CD-HIT package is very simple:
download current CD-HIT at http://bioinformatics.org/cd-hit, for example cd-hit-2006-0215.tar.gz
unpack the file with ” tar xvf cd-hit-2006-0215.tar.gz --gunzip”
change dir by “cd cd-hit-2006”
compile the programs by “make”
you will have all cd-hit programs compiled
I followed these steps and indeed .exe files were made:
cdhit.c++ cdhit-est-2d.c++ clstr_select_rep.pl
cd-hit.exe cd-hit-est-2d.exe clstr_size_histogram.pl
cdhit.o cdhit-est-2d.o clstr_size_stat.pl
cdhit-2d.c++ cd-hit-para.pl clstr_sort_by.pl
cd-hit-2d.exe cdhit-utility.c++ clstr_sort_prot_by.pl
cdhit-2d.o cdhit-utility.h clstr_sql_tbl.pl
cd-hit-2d-para.pl cdhit-utility.o clstr_sql_tbl_sort.pl
cdhit-454.c++ ChangeLog clstr2tree.pl
cd-hit-454.exe clstr_cut.pl clstr2txt.pl
cdhit-454.o clstr_list.pl clstr2xml.pl
cd-hit-auxtools clstr_list_sort.pl doc
cdhit-common.c++ clstr_merge.pl FET.pl
cdhit-common.h clstr_merge_noorder.pl license.txt
cdhit-common.o clstr_quality_eval.pl make_multi_seq.pl
cdhit-div.c++ clstr_quality_eval_by_link.pl Makefile
cd-hit-div.exe clstr_reduce.pl plot_2d.pl
cdhit-div.o clstr_renumber.pl plot_len1.pl
cd-hit-div.pl clstr_rep.pl psi-cd-hit
cdhit-est.c++ clstr_reps_faa_rev.pl README
cd-hit-est.exe clstr_rev.pl usecases
cdhit-est.o clstr_select.pl
However when I typ: cd-hit-est in the cygwin command line, it will say: -bash: cd-hit.exe: command not found. I'm not able to figure out why this is happening. Even when I'm in the folder were the .exe files are located it still will give the same error.
When you try to run command without a path, bash tries to find the command name in each directory from the PATH environment variable.
Usually current directory "." is not in the PATH so you have to run command adding absolute or relative path before command name:
./cd-hit.exe
or
/absolute/path/to/your/cd-hit/program/cd-hit.exe
If you want to permanently run command cd-hit.exe from anywhere, just add the directory where cd-hit was compiled to any existing auto-loaded bash profile files:
.profile
.bashrc
.bash_profile
like
PATH=$PATH:/absolute/path/to/your/cd-hit/program
export PATH
On installation of Pik, it seems that the directory naming conventions utilized in the program are erroneous, as can be seen below where C: is not reconciled as C:\ for the install directory. I suspect this my be the culprit. My PATH definitely does contain C:\cygwin64 as a variable, but it isn't recognized by Pik.
I have tried altering the name of the directory as C:\\cygwin64 during installation as a workaround and other similar variations just for the sake of trial and error, but to no avail. Interestingly, the Github directory shows a similar double backslash naming convention for this component, but I'm not sure how this might solve the problem.
The version of Pik I am using is 0.2.8.
$ pik_install C:\cygwin64
Thank you for using pik.
mkdir -p C:cygwin64
mkdir -p C:\Users\Adam/.pik
Installing to C:cygwin64
cp /home/Name/.gem/ruby/gems/pik-0.2.8/tools/pik_runner.exe C:cygwin64
cp /home/Name/.gem/ruby/gems/pik-0.2.8/tools/pik.bat C:cygwin64
cp /home/Name/.gem/ruby/gems/pik-0.2.8/tools/pik.ps1 C:cygwin64
creating C:\Users\Name/.pik/.pikrc
pik is installed
The directory you installed to is not in the sytem path.
C:cygwin64
You will need to add it.
if you want to use pik with git bash, add the following line to your ~/.bashrc:
[[ -s $USERPROFILE/.pik/.pikrc ]] && source $USERPROFILE/.pik/.pikrc
From the (slightly) outdated documentation on pyrocksdb, it says:
"If you do not want to call make install export the following enviroment variables:"
$ export CPLUS_INCLUDE_PATH=${CPLUS_INCLUDE_PATH}:`pwd`/include
$ export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:`pwd`
$ export LIBRARY_PATH=${LIBRARY_PATH}:`pwd`
But the installation instructions for RocksDB do not seem to mention any sort of install target!
Is there an accepted procedure for installing RocksDB from source?
My thoughts are to just copy the contents of the include directory from the rocksdb directory into somewhere like /usr/local/include and copy the librocksdb.so and librocksdb.a files into /usr/local/lib. Is this an acceptable method?
Note: The method of exporting environment variables was less preferable to me, as I built rocksdb in a directory inside my home folder--I am hoping for a cleaner solution (interpret that how you want).
RocksDB recently has make install. If you use the latest version, you should be able to do make install in RocksDB.
There is no install target in the current Makefile.
This breaks the long-established conventions for writing Makefiles (or pretty-much every other build system...); it should be considered a defect.
Without spending a lot of time analysing I can't be sure, but the install target should be something like:
prefix=/usr/local
bindir=$(prefix)/bin
# Normally you'd write a macro for this; 'lib' for 32-bit, 'lib64' for 64...
libdir=$(prefix)/lib64
includedir=$(prefix)/include
# Define this to be the directory(s) the headers are installed into.
# This should not include the 'include' element:
# include/rocksdb/stuff -> rocksdb/stuff
HEADER_DIRS=...
# Define this so all paths are relative to both the $CWD/include directory...
# so include/rocksdb/foo.h -> HEADER_FILES=rocksdb/foo.h
HEADER_FILES=...
.PHONY: install
install: $(TOOLS) $(LIBRARY) $(SHARED) $(MAKEFILES)
mkdir -p $(DESTDIR)$(bindir)
mkdir -p $(DESTDIR)$(libdir)
mkdir -p $(DESTDIR)$(includedir)
for tool in $(TOOLS); do \
install -m 755 $$tool $(DESTDIR)$(bindir); \
done
# No, libraries should NOT be executable on Linux.
install -m 644 $(LIBRARY) $(DESTDIR)$(libdir)
install -m 644 $(SHARED3) $(DESTDIR)$(libdir)
ln -s $(SHARED3) $(DESTDIR)$(libdir)/$(SHARED2)
ln -s $(SHARED2) $(DESTDIR)$(libdir)/$(SHARED1)
for header_dir in $(HEADER_DIRS); do \
mkdir -p $(DESTDIR)$(includedir)/$$header_dir; \
done
for header in $(HEADER_FILES); do \
install -m 644 include/$$header $(DESTDIR)$(includedir)/$$header; \
done
This will then allow you to install the files into /usr/local, by simply doing:
make install
However, the reason it's so heavily parameterised, is so you can change the destination folder, without having to modify the Makefile. For example, to change the destination to /usr, you simply do:
make prefix=/usr install
Alternatively, if you'd like to test the installation process, without messing with your filesystem, you could do:
make DESTDIR=/tmp/rocksdb_install_test prefix=/usr install
This would put the files into /tmp/rocksdb_install_test/usr which you can then check to see if they're where you want them to be... when you're happy, you can just do rm -Rf /tmp/rocksdb_install_test to cleanup.
The variables I've used are essential for packaging with RPM or DEB.
I an use ubuntu 16.04
DEBUG_LEVEL=0 make shared_lib install-shared
In this way, the installation is already generated in the production mode.
If you want to save time, you can specify the quantities of processors used in the process by passing -j[n], in my case, -j4
DEBUG_LEVEL=0 make -j4 shared_lib install-shared
In the case of ubuntu, this is sufficient, but in the case of ubuntu for docker, you should specify where the lib was installed.
export LD_LIBRARY_PATH=/usr/local/lib
Hope this helps.
Kemper