3

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).

therealrootuser
  • 10,215
  • 7
  • 31
  • 46

3 Answers3

3

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.

3

RocksDB recently has make install. If you use the latest version, you should be able to do make install in RocksDB.

keelar
  • 5,814
  • 7
  • 40
  • 79
0

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

Helmut Kemper
  • 662
  • 1
  • 6
  • 15