Rust-rocksdb: 시스템 RocksDB와 연결

이와 관련하여 이러한 환경 변수가 README 및 문서에 문서화되어 있으면 좋을 것입니다!

이것은 정말 유용할 것입니다!

openssl-sys 대한 빌드 파일은 여기에서 영감을 얻을 수 있는 좋은 장소일 수 있습니다.

나는 이것에 노력하고있다

@lovesegfault 진행 상황은 어떻습니까? rockdb 빌드는 현재 내 프로젝트 빌드 시간의 가장 큰 부분입니다 :cry:

지금 시스템 라이브러리를 사용하는데 어떤 문제가 있습니까? AFAIK, pkg-config 또는 env 변수를 통해 잘 작동합니다.

@aleksuss 글쎄, 현재 master 에서 librocksdb-sys 를 빌드하려고 하면 시스템 전체 라이브러리로 rockdb를 설치했음에도 불구하고 여전히 많은 C++ 컴파일러 인스턴스를 회전시킵니다.

$ ls /usr/lib/librocksdb.so*
/usr/lib/librocksdb.so  /usr/lib/librocksdb.so.6  /usr/lib/librocksdb.so.6.5.3

사무실에서 다른 일을 우선시했기 때문에 나는 이 일을 그만두었습니다. 앞으로 2주정도 휴가를 가는데, 다시 받아볼 수 있기를 :)

#354는 라이브러리 발견 마법을 추가하지 않습니다. 대부분 RocksDB가 pkg-config 또는 기타 유사한 도구를 지원하지 않기 때문입니다.

앞으로는 해당 envvar가 설정되지 않은 경우 일반적인 위치에서 라이브러리를 찾는 간단한 절을 쉽게 추가할 수 있습니다.

아, 알겠습니다. 크레이트가 _현재_ 시스템 전체의 RocksDB를 찾는 데 실패하더라도 계속 그럴 것입니다. 무엇이 실패하게 만드는지 궁금합니다. 단지 호환되는 버전이 아니라 .so 의 동일한 버전을 _정확히_ 찾는 것일까요?

글쎄, 현재 크레이트는 시스템 rockdb 및 공급업체를 찾을 수 없는 경우 찾으려고 시도합니다. #354는 기능을 통해 공급업체 여부를 선택한다는 의미입니다. 공급업체가 아닌 경우 ROCKSDB_LIB_DIR 설정해야 하며 그렇지 않으면 유용한 오류 메시지를 받게 됩니다.

envvar가 설정되지 않은 경우 라이브러리를 찾으려고 시도하는 후속 조치를 추가할 수 있습니다. 저는 일반적으로 해당 동작의 팬이 아닙니다.

@lovesegfault 내가 제대로 읽고 있는지 확실하지 않습니까? 그래서, 현재 ROCKSDB_LIB_DIR 가 설정되어 있지 _않다면, 그러면 rockdb _will_ vendor? 그리고 시스템 전체 lib와 연결하는 _유일한_ 방법은 ROCKSDB_LIB_DIR .

궁금합니다. 기본적으로 시스템 라이브러리를 사용하는 것을 반대하는 이유는 무엇입니까? 공급업체는 _거대한_ 컴파일 시간을 가져오는데, 장점이 무엇인지 잘 모르겠습니다.

@joonhoo
현재 행동
librocksdb-sys 는 ROCKSDB_LIB_DIR 변수를 찾습니다. 설정되어 있으면 해당 디렉토리의 .so 에 연결됩니다. 설정되지 않은 경우 대안으로 rockdb를 공급합니다. _exact_ 같은 동작은 같은 압축 라이브러리를 발생 bzip2 변수와 거기 BZIP2_LIB_DIR , 예를 들면.

새로운 행동
librocksdb-sys 에는 새로운(기본) 기능 vendor 있습니다. 해당 기능이 활성화되면 어떤 방식으로든 시스템 라이브러리를 찾으려고 하지 않습니다. 대신 rocksdb 및 모든 압축 라이브러리를 공급합니다.

vendor 기능이 활성화 되지 않은 경우 librocksdb-sys 는 어떠한 방식으로도 rockdb 및 압축 라이브러리를 포함한 라이브러리를 공급하려고 시도하지 않습니다. 대신 필요한 라이브러리를 찾을 위치를 알려주는 환경 변수를 찾습니다. 이러한 환경 변수는 LIBNAME_LIB_DIR 입니다. 시스템 라이브러리 검색을 시도하지 않고 사용자 지정에 의존합니다. vendor 비활성화하고 해당 환경 변수를 설정하는 것을 잊으면 설정하라는 메시지와 함께 빌드가 실패합니다. 환경.

가능한 미래 행동
앞으로 vendor 가 비활성화되면 환경 변수가 설정되지 않은 경우 폴백으로 시스템 라이브러리 검색을 시도할 수 있습니다. 아직 구현하지는 않았지만 시간이 있을 때 구현하려고 합니다.

기능으로 이 작업을 수행하는 것은 약간 이상합니다. 왜냐하면 종속성 트리의 _any_ 크레이트에 vendor 기능 세트와 함께 rocksdb 가 포함되어 있으면 RocksDB가 공급된다는 의미이기 때문입니다. 작은 상자에는 큰 차이가 없을 것이지만 RocksDB에 여러 전이 종속성을 가질 수 있는 큰 바이너리의 경우 공급업체를 선택 해제할 방법이 없을 가능성이 높습니다.

@jonhoo 맞아요 ,

IMHO는 판매가 전혀 없어야하며 판매는 모든 악의 근원입니다. @aleksuss 와 다른 유지 관리자가 그것을 허용한다면 나는 함께 판매를 없애는 것을 선호합니다.

나는 당신의 말에 동의합니다. 해결책은 공급업체가 아닌 것입니다. 최소한 벤더링은 기본 기능 세트에 포함되어서는 안 됩니다. 한 가지 옵션은 환경 변수를 사용하여 공급업체가 옵트인하도록 하는 것입니다.

그렇게 할 수 있습니다. @aleksuss @vitvakatu 여러분 생각은 어떤가요?

전이적 종속성의 경우 기능을 제어하기가 실제로 어렵고 소스에서 RocksDB를 컴파일하는 데 많은 비용이 듭니다(우리 프로젝트의 경우 빌드 시간이 약 30% 증가합니다!). 그러나 나는 벤더링을 완전히 제거한다는 아이디어를 좋아하지 않습니다. 일부 플랫폼에서는 사용 가능한 최신 rockdb 버전이 없습니다. 심지어 이전 Ubuntu 배포판에 대해 자체 PPA를 만들어야 했습니다.

따라서 현재 동작을 저장하는 것을 선호하지만 개선할 수 있습니다(자동 라이브러리 검색?). 아마도 우리는 사용자가 (env var를 통해) 수동으로 벤더링을 활성화해야 할 수도 있지만, 전이적 종속성에도 약간 성가실 것입니다.

글쎄, 현재 마스터에서 librocksdb-sys를 빌드하려고 하면 시스템 전체 라이브러리로 rockdb를 설치했음에도 불구하고 여전히 많은 C++ 컴파일러 인스턴스를 회전시킵니다.

이것은 또한 꽤 이상해 보이며 아마도 수정되어야 할 것입니다.

@vitvakatu 예, 사용자가 벤더링을 선택하도록 동작을 "반전"하는 것이 올바른 방법이라고 생각합니다. :)

이것은 또한 꽤 이상해 보이며 아마도 수정되어야 할 것입니다.

env vars가 설정되어 있지 않으므로 이것이 오늘의 의도된 동작이라고 생각합니다.

좋아, 나는 행동을 뒤집었다 :)

@lovesegfault 제 생각에는 동작을 반전시키는 경우 build.rs rocksdb 가 /usr/lib 또는 기본적으로 rocksdb 에서 /usr/lib rocksdb 를 검색하도록 해야 합니다. 그렇지 않으면 많은 사용자가 env var 세트가 없기 때문에 갑자기 컴파일 오류가 발생합니다.

좋습니다. 보류 중인 작업은 다음과 같습니다.

• 도서관 발견
• vendor 기능을 envvar로 전환