[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/6] gnu: Add rocksdb.

From: Ludovic Courtès
Subject: Re: [PATCH 4/6] gnu: Add rocksdb.
Date: Wed, 18 Jan 2017 22:29:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Marius Bakke <address@hidden> skribis:

> Ludovic Courtès <address@hidden> writes:
>> Marius Bakke <address@hidden> skribis:
>>> * gnu/packages/databases.scm (rocksdb): New variable.
>> [...]
>>> +           (lambda* (#:key (make-flags '()) #:allow-other-keys)
>>> +             ;; Prevent the build from adding machine-specific 
>>> optimizations.
>>> +             ;; This does not work if passed as a make flag...
>>> +             (setenv "PORTABLE" "1")
>>> +             (and (zero? (apply system* "make" "static_lib" make-flags))
>>> +                  (zero? (apply system* "make" "shared_lib" make-flags)))))
>> We could avoid building the static libs if nothing requires it; no
>> strong opinion though.
> I do tend to simply drop the static libs (see e.g. "dlib" or
> "capnproto"), but in this case Ceph requires the static library. I will
> make another attempt at making it use "-lrocksdb" instead of the ".a"
> before pushing this package however, now that I know the build better.


> In the crypto++ case, static is the default make target, so I suspect
> it's "normal" to use. But as I recently realized, grafting most likely
> won't work with static libraries, so I will remove it. Being a crypto
> library and all. We should discourage it indeed.

Indeed.  So it’s best to avoid static libs whenever possible.

>>> +    (home-page "";)
>>> +    (synopsis "Persistent key-value store for fast storage")
>>> +    (description
>>> +     "RocksDB is an embeddable, persistent key-value storage library that 
>>> is
>>> +designed for flash and RAM storage.")
>> Could you expound a little bit?
> How about:
> (synopsis "Persistent key-value store for flash and RAM storage")
> (description
>   "RocksDB is a library that forms the core building block for a fast
>   key-value server, especially suited for storing data on flash drives.
>   It has a Log-Structured-Merge-Database (LSM) design with flexible
>   tradeoffs between Write-Amplification-Factor (WAF),
>   Read-Amplification-Factor (RAF) and Space-Amplification-Factor (SAF).
>   It has multi-threaded compactions, making it specially suitable for
>   storing multiple terabytes of data in a single database.
>   It is based on @code{LevelDB}.")

Perfect, thanks!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]