Marius Bakke <mba...@fastmail.com> skribis: > Ludovic Courtès <l...@gnu.org> writes: > >> Marius Bakke <mba...@fastmail.com> 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.
OK. > 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 "http://rocksdb.org/") >>> + (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! Ludo’.