Libelektra: 녹 바인딩

Rust에 대해 잘 모르지만 rust-bindgen 의해 생성된 바인딩은 unsafe Rust에서만 사용할 수 있다고 가정합니다. 그런 경우라면 좀 더 관용적인 Rust API를 사용하는 래퍼가 있으면 좋을 것입니다.

AFAIK 대부분의 Rust 바인딩에는 C API의 1:1 매핑을 위한 하나의 *-sys 크레이트와 대부분의 사용자가 Rust에서 실제로 사용할 API가 포함된 다른 크레이트가 있습니다. Rust에게 자동으로 keyDel , ksDel 및 필요할 때 친구를 호출하도록 지시하는 방법이 있다면 정말 좋을 것입니다.

그런 경우라면 좀 더 관용적인 Rust API를 사용하는 래퍼가 있으면 좋을 것입니다.

예, 이것이 계획입니다. 그리고 그렇게 하는 동안 C API와 비교하고 C API(적어도 문서에서)에서 개선점을 찾을 수 있습니다.

@PhilippGackstatter 논의된 대로: https://crates.io/ 에 업로드하는 방법과 CMake 시스템에 바인딩을 통합하는 방법도 알아보세요.

@PhilippGackstatter 어떤 진전이 있습니까? Rust 바인딩을 확장하는 데 관심이 있을 수도 있는 사람이 있습니다.

@markus2330 며칠 전에 시작했지만 대부분 bindgen, cmake 및 프로젝트에 통합하는 방법에 대해 읽고 있었기 때문에 보여줄 것이 없었습니다. 하지만 지금은 처음 몇 가지를 준비했습니다(#2826 참조). 지금은 프로젝트를 완전히 진행하고 있습니다.

#2826의 질문에 답하려면(PR은 코드와 직접 관련이 없는 토론에 대해 혼동을 일으키는 경향이 있으므로 문제에 대한 질문을 선호하십시오):

하나는 바인딩을 생성해야 하는 src/include의 헤더입니다. 최소한 kdb.h이지만 플러그인 지원 없이 저수준 API에 필요한 다른 것들이 있습니까?

아니요, 저수준 API는 kdb.h에만 있습니다.

다른 하나는 Rustup(cargo 및 rustc를 설치하는 데 사용됨)을 설치하기 위해 모든 도커 스크립트를 변경해야 합니까?

예, 도커 스크립트와 Jenkinsfile도 변경해야 합니다. 그러나 최신 배포판용으로 빌드하는 경우 모든 항목을 변경할 필요는 없습니다.

Debian Buster에 번들로 제공되는 기본 Rust로 컴파일할 수도 있다면 좋을 것입니다. 데비안 버스터 도커 파일이 아직 병합되지 않았습니다. #2819

자동화된 방법은 없다고 생각합니다.

이를 위한 몇 가지 아이디어가 있습니다. #730

Rust-bindgen은 바인딩을 생성하는 두 가지 방법을 제공합니다. 하나는 명령줄을 통한 것이므로 수동 프로세스이므로 C-API에서 변경 사항이 있는 경우 반복해야 합니다. 다른 하나는 화물 빌드가 실행될 때마다 실행되는 빌드 스크립트를 통한 것입니다. 즉, 각 빌드에서 바인딩이 다시 생성됩니다. 이것이 현재 구현된 것입니다. 그러나 바인딩을 사용하는 모든 사람이 elekra에 필요한 헤더를 가져야 합니다. 누군가가 elektra를 설치했지만 컴파일하지 않았다면 필요한 모든 요구 사항을 충족하지 못할 수도 있습니다. C-API가 더 이상 많이 변경되지 않기 때문에 때때로 수동으로 헤더를 재생성하는 것이 더 합리적일 수 있습니까?

모든 빌드에서 재생성이 적절한 솔루션인 것 같으며 다른 바인딩도 그렇게 작동합니다(swig를 설치해야 함). 설명하는 문제를 피하기 위해 생성된 헤더 파일을 간단히 설치할 수 있습니다.

예, 이것이 계획입니다. 그리고 그렇게 하는 동안 C API와 비교하고 C API(적어도 문서에서)에서 개선점을 찾을 수 있습니다.

지금까지 개선을 위한 몇 가지 사소한 기회를 찾았습니다.

• keyGetBinary : 호출 코드로서 -1의 반환 값이 maxSize is 0 또는 type mismatch 또는 다른 것을 의미하는지 알 수 없습니다. Rust는 반환 인수에서 명시적 오류 처리를 사용하기 때문에 유형 불일치를 오류에 일치시키고 "maxSize related" 오류를 다른 오류에 일치시킬 수 있기를 바랍니다. 그러나 현재 더 일반적인 오류를 사용해야 합니다. 유형 불일치를 직접 확인할 수도 있지만 keyGetBinary 가 그렇게 하므로 동일한 검사를 두 번 받습니다.
  keySetName 는 두 개의 다른 오류를 -1에 일치시키는 유사한 작업을 수행합니다. 두 경우 모두 버그(잘못된 이름)인 오류와 사운드 프로그램(키셋에 이미 있는 키)에서 발생할 수 있는 오류가 있으므로 결정을 이해할 수 있습니다. 그러나 명시성과 이중 검사를 피하기 위해 -2를 사용하지 않는 이유는 무엇입니까?
• 문법적으로는 keyIsDirectBelow 가 keyIsDirectlyBelow 아니어야 합니까 🙂? 그렇다면 Rust API에서 이것을 수정해야 합니까?

또 다른 질문: keyRel 는 CPP 바인딩에서 구현되지 않습니다. Rust에서도 이것을 생략해야 합니까?

훌륭한 작업입니다. 귀하의 질문에 따르면 이미 API를 자세히 살펴보았음을 알 수 있습니다.

유형 불일치를 직접 확인할 수 있지만 keyGetBinary가 이를 수행하므로 동일한 검사를 두 번 수행합니다.

잘못된 호출을 피하기 위해 typesystem을 사용할 수도 있습니까? (keyGetBinary는 바이너리 키에서만 허용됩니다)

그러나 명시성과 이중 검사를 피하기 위해 -2를 사용하지 않는 이유는 무엇입니까?

그 이유는 호환성 때문이었습니다. API는 처음에 -1만 반환했으며 기존 프로그램을 중단하지 않고 다른 오류 코드를 추가할 수 없습니다(오류를 확인하기 위해 ==-1 가 있을 수 있음). 그러나 다음 릴리스(0.9)에서는 API를 다시 중단할 수 있습니다. 그리고 0 미만의 값은 오류를 나타냄으로써 호환성 문제를 피할 수 있습니다. 나는 바인딩이 정확한 오류를 생성해야 한다는 데 전적으로 동의합니다.

이러한 API 문제를 해결하시겠습니까?

그렇다면 Rust API에서 이것을 수정해야 합니까?

API는 철자가 다르지 않아야 합니다. 수정하면 C API 및 모든 바인딩에서 수정해야 합니다(실제로 Java 및 Go만 수동으로 조정해야 하며 나머지는 어쨌든 올바르게 재생성됩니다).

keyRel은 CPP 바인딩에서 구현되지 않습니다. Rust에서도 이것을 생략해야 합니까?

예, 이미 keyIs(Direct)Below 및 keyRel에 겹치는 기능이 있음을 알았을 수 있습니다. keyRel의 아이디어는 API를 작게(따라서 라이브러리를 작게) 유지하는 것이었습니다. 그러나 keyRel을 있는 그대로 사용할 수 없고 느립니다. 따라서 0.9 이내에 제거할 가능성이 높습니다. 제거될 다른 후보자에 대해서는 doc/todo/FUTURE를 참조하십시오.

잘못된 호출을 피하기 위해 typesystem을 사용할 수도 있습니까? (keyGetBinary는 바이너리 키에서만 허용됩니다)

좋은 아이디어야. BinaryKey 및 StringKey 가질 수 있으며 첫 번째에만 get_binary() 메서드가 있고 두 번째에만 get_string() 메서드가 있는 식입니다. 나는 이것을 조사할 것이다.

이러한 API 문제를 해결하시겠습니까?

나는 그걸 할 수있어. 나에게 우선순위가 무엇인지에 달려 있습니다. Rust에 대한 안전한 API를 마친 후 Rust에도 플러그인 API가 있으면 좋겠다고 하셨습니다. 더 중요한 것을 결정할 수 있습니다.

좋은 아이디어야. BinaryKey 및 StringKey를 가질 수 있으며 첫 번째에만 get_binary() 메서드가 있고 두 번째에만 get_string() 메서드가 있는 식입니다. 나는 이것을 조사할 것이다.

감사합니다. 너무 많은 캐스트가 필요할 수 있으므로 좋은 생각인지 살펴보겠습니다. 또한 다른 유형이 키 세트의 키에 유용할 수 있습니다(setName이 허용되지 않는 경우).

나는 그걸 할 수있어. 나에게 우선순위가 무엇인지에 달려 있습니다. Rust에 대한 안전한 API를 마친 후 Rust에도 플러그인 API가 있으면 좋겠다고 하셨습니다. 더 중요한 것을 결정할 수 있습니다.

예, 먼저 kdb.h에서 Rust API를 완료한 다음 몇 시간을 더 소비해야 하는지 알 수 있습니다.

IMO Rust 바인딩(및 해당 문제에 대한 바인딩)에는 두 가지 버전이 있어야 합니다. 하나는 C API를 최대한 가깝게 미러링하는 것이고 다른 하나는 첫 번째 버전을 기반으로 하는 언어에 더 관용적입니다. BinaryKey 및 StringKey (또는 제네릭)이 있는 유형 시스템을 사용하는 관용적 버전에서 Rust의 API를 더 쉽게 사용할 수 있다면 아마도 좋은 생각일 것입니다.

@kodebach 동의합니다. 그리고 이것은 elektra 및 elektra-sys 상자에서도 수행되는 것 같습니다.

@kodebach 동의합니다. 그리고 이것은 elektra 및 elektra-sys 상자에서도 수행되는 것 같습니다.

그래요. 저도 그렇게 생각 해요. 안전한 Rust API에 해결해야 하는 제한 사항이 있는 경우 elektra_sys 가져오고 일대일 C 바인딩 함수를 직접 호출할 수 있습니다.

감사합니다. 너무 많은 캐스트가 필요할 수 있으므로 좋은 생각인지 살펴보겠습니다. 또한 다른 유형이 키 세트의 키에 유용할 수 있습니다(setName이 허용되지 않는 경우).

핵심 구현에 매우 효과적이었습니다. 그러나 KeySet의 경우 장애물에 부딪혔습니다. Key를 반환하는 모든 메서드는 내가 만든 공통 인터페이스를 따라야 합니다. 일반 반환 매개 변수가 있는 get_value 메서드를 구현했습니다. BinaryKeys의 경우 바이트이고 StringKeys의 경우 문자열입니다. 그러나 ksNext 의 녹 버전은 이제 무엇을 반환합니까? "핵심 인터페이스"를 만족하지만 어떤 값을 갖는 객체입니까? 하나를 선택해야합니다.
이것은 시그니처의 모습이어야 하며, 여기서 Value는 get_value 반환하는 유형입니다. 바이트( Vec<u8> ) 또는 문자열만 지정할 수 있습니다.
pub fn next(&mut self) -> Box<dyn WriteableKey<Value = Vec<u8>>>;

따라서 바이트로 통합할 수 있지만 사용자가 직접 문자열로 변환해야 합니다. StringKey와 BinaryKeys의 유일한 차이점은 set_value 및 get_value 구현뿐이므로 이 변경으로 명시성이 제거되고 기본적으로 키만 다시 갖게 됩니다.

실제 문제는 현재 구현의 KeySet에 포함된 키의 종류에 대해 명시적이지 않지만 *키는 있다는 것입니다. 그러나 KeySet의 인스턴스에 StringKey 또는 BinaryKey만 포함하도록 허용하는 것은 너무 큰 제한입니다.
나는 Key와 KeySet 둘 다 그들이 무엇을 포함하고 있는지 또는 전혀 포함하지 않았는지에 대해 명시적이어야 한다고 생각합니다. 나는 이제 나머지 elektra와 일관성을 유지하기 위해 일반 Key 및 KeySet에 기대고 있습니다.
이견있는 사람?

사용성 관점에서 볼 때 가장 자주 사용되는 변형이므로 String에 대한 getter가 있는 Key를 반환하는 것이 좋습니다. 이 키(next에 의해 반환됨)가 KeySet의 일부라는 것을 이미 알고 있기 때문에 이름에 대한 설정자는 비활성화되어야 합니다(쉽게 가능한 경우).

일반적으로 유형 시스템은 방해가 되지 않고 사용자를 지원해야 합니다. 따라서 가능한 한 간단하게 유지하십시오. 가장 일반적인 오류는 다음과 같습니다.

1. 키 세트에 있는 키의 키 이름을 변경하려고 합니다.
2. 메타 데이터 키(또는 다른 const 키)를 변경하려고 합니다.
3. 혼란스러운 Key/KeySet 복제 및 참조.
4. 반복이 더 이상 올바르게 작동하지 않는 방식으로 키를 잘라내는 데에도 사용되는 KeySet를 반복합니다.
5. Key/KeySet 해제를 잊어버린 경우

따라서 유형 시스템이 거기에 도움이 될 수 있다면 좋을 것입니다. 5. 1. 및 2. 당신의 추상화가 도움이 될 것이기 때문에 설계상 가능하지 않기를 바랍니다.

이진/문자열 혼동은 실제로 다소 드문 오류입니다(이진 키가 매우 비정형적이기 때문에 대부분 함수 포인터를 보유하는 데 사용됨).

ㅋ API의 안전한 사용에 대한 설계 결정을 작성하려면 계속 진행하십시오(doc/decision).

사용성 관점에서 볼 때 가장 자주 사용되는 변형이므로 String에 대한 getter가 있는 Key를 반환하는 것이 좋습니다.

그러나 모든 바이트 시퀀스가 ​​유효한 UTF-8은 아니므로 더 이상 유형 안전하지 않을 것입니다. 그렇지 않습니까?

Rust의 AFAIK 매크로 시스템은 매우 강력합니다. 아마도 항상 올바른 유형을 반환하는 함수를 작성하는 방법이 있을 것입니다. 예를 들어 Kotlin에는 맵이 키의 값 유형을 인코딩하는 기술이 있습니다. 이 API 참조 를 통해 여기가 예입니다.

대안 StringKeySet 만이 수락하는 StringKey 바이너리 키가 매우 드물고 주로 구성에 사용하지 않기 때문에,의 힘의 메이크업 감각.

사용성 관점에서 볼 때 가장 자주 사용되는 변형이므로 String에 대한 getter가 있는 Key를 반환하는 것이 좋습니다. 이 키(next에 의해 반환됨)가 KeySet의 일부라는 것을 이미 알고 있기 때문에 이름에 대한 설정자는 비활성화되어야 합니다(쉽게 가능한 경우).

그러나 드물기는 하지만 혼합 키가 있는 KeySet을 갖는 것은 여전히 ​​가능합니다. 그런 다음 항상 StringKey를 반환하고 get_string 호출하면 오류가 발생하지만 해당 유형에는 get_binary 메서드가 없기 때문에 유형 시스템은 이를 허용할 뿐만 아니라 이에 대해 안내합니다.

그렇게 하기 전에 KeySet을 일반화하고 사용자가 내부에 StringKeys만 있다고 확신하는 경우 KeySet<StringKey> 로 인스턴스화하는 것이 좋습니다(Rust에서 제공하지 않는 KeySet의 경우). 그런 다음 반복하면 StringKey만 생성되는 것이 당연합니다.
또한 KeySet이 유형 시스템을 통해 동질적임을 강제합니다. 최소한 Rust 사용자가 만든 유형 시스템은 전반적으로 더 안전합니다.
드문 경우지만 바이너리 키가 예상되는 경우 사용자는 is_binary 및 is_string 로 확인한 다음 변환해야 하며 이는 안전한 메서드 호출입니다.

혼란스러운 Key/KeySet 복제 및 참조.

내가 할 수 있는 유일한 일은 ref count보다 복제의 사용을 촉진하는 것뿐이라고 생각합니다. 성능 면에서 더 나쁠 수 있지만 keyDel은 Rust에 의해 자동으로 호출되는 반면 ref 카운팅은 완전히 수동입니다. 따라서 복제는 참조 계산보다 확실히 더 쉽습니다.

반복이 더 이상 올바르게 작동하지 않는 방식으로 키를 잘라내는 데에도 사용되는 KeySet를 반복합니다.

키세트를 반복하는 동안 키세트를 수정하는 것을 의미합니까?

ㅋ API의 안전한 사용에 대한 설계 결정을 작성하려면 계속 진행하십시오(doc/decision).

그 내용은 무엇이었을까요?

Rust의 AFAIK 매크로 시스템은 매우 강력합니다. 아마도 항상 올바른 유형을 반환하는 함수를 작성하는 방법이 있을 것입니다.

무엇이든 포함할 수 있고 구체적인 키 유형을 포함할 수 있는 KeySet의 "현재" 디자인은 적어도 제대로 작동하지 않는다고 생각합니다. 하지만 매크로를 살펴보겠습니다.

그러나 모든 바이트 시퀀스가 ​​유효한 UTF-8은 아니므로 더 이상 유형 안전하지 않을 것입니다. 그렇지 않습니까?

Elektra의 문자열이나 바이너리 값은 UTF-8일 필요가 없습니다. Elektra는 문자열과 바이너리 사이에서만 결정합니다(0바이트를 포함할 수 있음).

Rust의 AFAIK 매크로 시스템은 매우 강력합니다. 아마도 항상 올바른 유형을 반환하는 함수를 작성하는 방법이 있을 것입니다. 예를 들어 Kotlin에는 맵이 키의 값 유형을 인코딩하는 기술이 있습니다. 여기 API 참조는 예시입니다.

우리는 또한 유용한 기능에 노력을 기울일 필요가 있습니다. 바이너리 키는 드물다.

또는 이진 키는 매우 드물고 대부분 구성에서 사용되지 않기 때문에 StringKeys만 허용하는 StringKeySet이 의미가 있을 수 있습니다.

예, 하지만 StringKeySet을 일반 KeySet으로 볼 수 있습니다.

그러나 드물기는 하지만 혼합 키가 있는 KeySet을 갖는 것은 여전히 ​​가능합니다. 그런 다음 항상 StringKey를 반환하고 get_string을 호출하면 오류가 발생하지만 해당 유형에 get_binary 메서드가 없기 때문에 유형 시스템은 이를 허용할 뿐만 아니라 이를 안내합니다.

예, 하지만 말했듯이 이것은 사소한 문제입니다. 함수 주소와 같은 바이너리 데이터를 저장하는 사람들은 키를 캐스팅하는 방법을 알게 될 것입니다(관련 문서가 있는 경우).

그렇게하기 전에 KeySet을 일반화하고 KeySet으로 인스턴스화하는 것이 좋습니다.사용자가 내부에 StringKeys만 있다고 확신하는 경우(Rust에서 제공하지 않는 KeySet의 경우). 그런 다음 반복하면 StringKey만 생성되는 것이 당연합니다.

KeySet은 KDB(외부적으로)에서 가져오고 어떤 경우에도 바이너리 데이터를 포함할 수 있기 때문에 가짜 안전일 뿐입니다. 따라서 저는 KeySet이 제네릭이 아닌 것을 선호합니다.

제네릭을 가지고 놀고 싶다면 KeySet을 (일반) 데이터 구조로 변환하는 getter 및 setter를 제공하십시오. 예를 들어 Elektra의 정수 배열은 Vec<i32> 입니다.

키세트를 반복하는 동안 키세트를 수정하는 것을 의미합니까?

예 cut 는 KeySet을 수정합니다. 일반적으로 반복자는 그렇게 하는 것이 안전하지만 많은 사람들이 올바르게 하는 데 문제가 있습니다.

그 내용은 무엇이었을까요?

여기에서 논의한 내용과 설계 방법에 대한 요약입니다.

무엇이든 포함할 수 있고 구체적인 키 유형을 포함할 수 있는 KeySet의 "현재" 디자인은 적어도 제대로 작동하지 않는다고 생각합니다.

나는 동의한다.

하지만 매크로를 살펴보겠습니다.

우선순위를 두지 마시기 바랍니다.

Elektra의 문자열이나 바이너리 값은 UTF-8일 필요가 없습니다.

그런 다음 빠른 검색에 따라 String 대신 OsString 또는 CString 를 사용해야 합니다.

Elektra의 문자열이나 바이너리 값은 UTF-8일 필요가 없습니다.

그런 다음 빠른 검색에 따라 String 대신 OsString 또는 CString 를 사용해야 합니다.

지금 저는 Rust의 String (UTF-8)를 elektra에 전달하기 전에 CString 로 변환하고 있습니다. 그 근거는 String 가 기본 문자열이고 대부분의 다른 라이브러리는 기본 문자열로 작동할 것으로 예상한다는 것입니다.
대신 String 가 필요한 경우 사용자가 변환 코드를 처리해야 하도록 고수준 API가 CString 요청하고 반환하도록 할 수 있습니다. 더 얇은 API를 만들고 처리해야 하는 오류 처리를 줄입니다. 대부분의 사용자가 API를 사용하기를 원하는 방식에 달려 있다고 생각합니다.

언어의 가장 일반적인 문자열 유형을 반환하는 것이 가장 좋다는 데 동의합니다. UTF8이 아닌 문자열은 드물어야 합니다(바이너리보다 훨씬 더 희귀할 수 있음).

언어의 가장 일반적인 문자열 유형을 반환하는 것이 가장 좋다는 데 동의합니다. UTF8이 아닌 문자열은 드물어야 합니다(바이너리보다 훨씬 더 희귀할 수 있음).

나는 UTF-8에서 C-string으로 가는 Rust -> C 방향을 처리하는 가장 좋은 방법을 알아 내려고 노력하고 있습니다. UTF-8 문자열은 0바이트를 포함할 수 있지만 표시 되는 유일한 코드포인트는 NUL 문자이며 그렇지 않은 경우는 아닙니다 . 문자열이 0바이트를 포함할 수 없다는 것을 바인딩 문서의 전제 조건으로 명시하는 것이 합리적이라고 생각합니다. 어쨌든 그 지점에서 코드 패닉이 발생합니다.

다른 가능성은 문자열을 사용하는 모든 집합 함수에서 오류를 반환하는 것입니다. 그러나 사용자는 항상 이 NulError 해야 하며 실제로는 반환조차 되지 않습니다.

keyNew 는 할당 오류 시 NULL 포인터를 반환할 수 있습니다. Rust에서는 명시적 오류나 패닉을 반환할 수 있지만 암시적 null은 반환할 수 없습니다. 신호 오류에 대한 중단 됩니다. Java 바인딩은 이 경우를 처리하지 않는 것 같으므로 NullPointerException 가 발생하므로 프로세스도 종료될 것이라고 가정합니다.
여기에서 패닉 을 호출하는 것이 가장

문자열이 0바이트를 포함할 수 없다는 것을 바인딩 문서의 전제 조건으로 명시하는 것이 합리적이라고 생각합니다. 어쨌든 그 지점에서 코드 패닉이 발생합니다.

예, 합리적입니다.

여기에서 패닉을 호출하는 것이 가장 좋다는 데 동의하십니까(중단은 소멸자가 실행되는 것을 허용하지 않음)?

예, malloc이 실패하면 당황하는 것이 합리적입니다. (Rust의 경우 stdlib가 동일한 작업을 수행합니다. C에서는 stdlib가 중단되지 않으므로 C-Elektra도 중단되지 않습니다).

이제 Rust 바인딩이 마스터로 병합되었으므로 crates.io에 게시하고 싶습니다.
바인딩과 elektra 자체의 성숙도가 다르기 때문에 elektra에 묶이는 대신 버전을 (기본값) 0.1.0 설정하여 게시하는 것이 좋습니다. @markus2330에 동의하십니까?

https://crates.io에 게시하려면 GitHub 계정이 필요합니다. 크레이트의 소유권은 계정 간에 이전될 수 있으므로 지금은 내 소유를 사용할 수 있습니다. 또는 다른 사람이 로그인하여 게시하는 데 필요한 API 토큰을 나에게 보낼 수 있습니다.

crates.io :sparkle에 게시해 주셔서 감사합니다.

Elektra 저장소의 일부이기 때문에 버전을 Elektra에 직접 연결합니다. 그러나 그것은 그다지 중요하지 않습니다. crates.io가 일반적으로 특정 버전 스키마를 가지고 있다면 거기에서 공통적인 것을 고수하는 것이 좋습니다.

또는 다른 사람이 로그인하여 게시하는 데 필요한 API 토큰을 나에게 보낼 수 있습니다.

공인인증서 로그인했습니다. API 토큰을 보내드리겠습니다.

Elektra 저장소의 일부이기 때문에 버전을 Elektra에 직접 연결합니다. 그러나 그것은 그다지 중요하지 않습니다. crates.io가 일반적으로 특정 버전 스키마를 가지고 있다면 거기에서 공통적인 것을 고수하는 것이 좋습니다.

이것의 주요 문제는 시맨틱 버전 관리에 따르면 바인딩에서 주요 변경을 수행해야 하는 경우 그에 따라 버전을 업그레이드할 수 없다는 것입니다. 따라서 우리는 elektra가 할 때만 주요 변경을 수행할 수 있습니다.

시맨틱 버전 관리에 따르면 버전이 0 시작하는 한 모든 주요 변경을 수행할 수 있습니다. Elektra 1.0 출시하면 바인딩도 안정적으로 유지하는 것이 중요합니다. 그리고 그렇게 하는 데 실패하더라도 미래에 버전을 독립적으로 만드는 옵션도 있습니다(단순히 Rust 바인딩의 주요 버전을 늘리십시오). 그래서 지금은 단순히 Elektra의 버전을 사용하는 것이 안전하다고 생각합니다.

맞습니다. 나중에 메이저 버전을 늘릴 생각은 없었습니다.

지금 wrapper.h #include "kdb.h" 를 지정하여 kdb 헤더를 포함하고 이에 대한 바인딩을 생성합니다. 그러나 clang은 헤더를 찾지 않습니다(예: ubuntu:18.10 에서). 따라서 빌드하려면 /usr/include/elektra 를 포함하도록 clang에 명시적으로 지시해야 합니다.
이 솔루션이 대부분의 배포판에서 작동하도록 elektra는 항상 /usr/include/elektra 설치되어 있습니까?

이 솔루션이 대부분의 배포판에서 작동하도록 elektra는 항상 /usr/include/elektra에 설치되어 있습니까?

예, /usr/include/kdb.h 를 사용하는 다른 라이브러리(Kerberos에서 생각함)가 있기 때문입니다.

지금은 /usr/include/elektra 가 포함 경로의 일부여야 하지만 AFAIK에서는 #include <elektra/kdb.h> 를 대신 사용할 수 있도록 변경하려고 합니다.

이 솔루션이 대부분의 배포판에서 작동하도록 elektra는 항상 /usr/include/elektra에 설치되어 있습니까?

기본적으로 /usr/local/include/elektra이지만 대부분의 배포판은 /usr/include/elektra를 사용하지만 보장은 없습니다. 그렇기 때문에 빌드 시스템에는 일반적으로 헤더 파일을 찾는 데 약간의 지원이 있습니다. Elektra는 cmake 및 pkg-config를 지원합니다.

이것이 필요한 위치에 대한 컨텍스트를 제공할 수 있습니까?

대신 사용할 수 있습니다.

대신 사용해야 합니다. 관련 PR은 #2880입니다.

#include <elektra/kdb.h> 변경하면 Ubuntu에서 확실히 작동합니다. 그러면 /usr/include/elektra 를 포함하는 대신 해당 경로로 변경하겠습니다.

#include <elektra/kdb.h> 변경하면 Ubuntu에서 확실히 작동합니다. 그러면 /usr/include/elektra 를 포함하는 대신 해당 경로로 변경하겠습니다.

모든 헤더에서 작동하지 않을 수 있으며 일부는 포함 경로에 있는 /usr/include/elektra 에 의존합니다.

아마도 가장 좋은 방법은 (가능한 경우) pkg-config 또는 cmake --find-package 를 사용하여 Elektra 파일을 찾는 것입니다(IMO cmake 가 더 잘 작동함).

이것이 필요한 위치에 대한 컨텍스트를 제공할 수 있습니까?

따라서 사용자가 자신의 컴퓨터에서 elektra를 컴파일하면 녹/화물만 필요하고 바인딩을 사용할 수 있습니다. 그러나 crates.io를 사용해야 하는 다른 사용 사례는 누군가가 패키지 관리자를 통해 elektra(및 헤더)를 설치하는 경우입니다. 그런 다음 라이브러리와 헤더를 사용할 수 있습니다. 이제 사용자는 종속 항목에 elektra를 포함하고 화물은 elektra-sys 상자를 가져옵니다. 빌드 스크립트와 clang에만 의존하여 바인딩을 생성합니다. 하지만 clang은 어떻게든 kdb.h 를 찾아야 합니다. 따라서 빌드 스크립트에서 추가 하드코딩된 포함 경로를 전달하거나 #include ... 문을 직접 수정할 수 있습니다.

아마도 가장 좋은 방법은 (가능한 경우) pkg-config 또는 cmake --find-package 를 사용하여 Elektra 파일을 찾는 것입니다(IMO cmake 가 더 잘 작동함).

빌드 종속성으로 pkg-config 또는 cmake를 추가하고 이 방법으로 kdb.h 찾을 수 있습니다. 나는 이것을 조사할 것이다. 이것이 가장 신뢰할 수 있는 방법이라는 데 동의합니다.

예, 빌드 스크립트에서 pkg-config를 호출할 수 있습니다. pkg-config를 사용할 수 없는 경우 /usr/include/elektra 및 /usr/local/include/elektra와 같은 하드 코딩된 경로를 시도할 수 있습니다. (crates.io에서 pkg-config를 사용할 필요가 없는 경우)

이 상자를 사용해 볼 수 있습니다.

예, 빌드 스크립트에서 pkg-config를 호출할 수 있습니다. pkg-config를 사용할 수 없는 경우 /usr/include/elektra 및 /usr/local/include/elektra와 같은 하드 코딩된 경로를 시도할 수 있습니다. (crates.io에서 pkg-config를 사용할 필요가 없는 경우)

선택적 종속성으로 pkg-config 를 추가했습니다. 추가되면 elektra를 검색하고 제공된 includedir를 사용합니다. 그렇지 않으면 이름을 지정한 두 디렉토리에서 검색합니다.

이제 바인딩이 게시됩니다. elektra 및 elektra-sys :smiley:

docs.rs 빌드 환경에서 libelektra의 누락된 시스템 종속성으로 인해 문서가 빌드되지 않았습니다. 또한 9월 30일에 빌드 환경이 변경됩니다.
9월 30일에 올바르게 빌드되도록 libelektra를 종속성으로 추가해 달라는 요청 을 제출했습니다. 그는 또한 기존 환경에 패키지를 추가하여 이제 문서 를 사용할 수 있습니다.+1:

#2980이 병합된 후에 이 문제를 종료할 수 있다고 생각합니다.

매우 훌륭합니다. 그들은 매우 빠르게 반응했습니다. 그들이 꽤 오래된 명예훼손으로 그것을 구축하는 것이 문제가 될까요? (어떤 버전인지는 확인하지 않았지만 패키지 관리자에서 포함시키면 확실히 0.9 이상 버전일 것입니다.)

elektra 상자는 문서일 뿐이므로 문제가 없습니다. elektra-sys 현재 버전 대신 생성된 elektra의 모든 버전이 포함되어 있다고 생각합니다. 하지만 래퍼 대신 원시 바인딩을 사용하는 사람은 거의 없을 것입니다. 따라서 문서가 자동으로 빌드되도록 하는 데 약간의 절충안이 있습니다.

그런 다음 저장소 내 문서에 대한 링크를 추가할 수 있습니까?

어쨌든 elektra-sys는 거의 사용할 수 없는 것 같습니다. Elektra와 관련이 거의 없는 수백 개의 기호를 보여줍니다. 또한 개별 기능에 대한 문서가 없습니다.

https://docs.rs/elektra-sys/0.9.0/elektra_sys/fn.keyString.html

그런 다음 저장소 내 문서에 대한 링크를 추가할 수 있습니까?

네, 기존 PR에 추가하겠습니다.

어쨌든 elektra-sys는 거의 사용할 수 없는 것 같습니다. Elektra와 관련이 거의 없는 수백 개의 기호를 보여줍니다.

나는 이것을 조사할 것이다.

또한 개별 기능에 대한 문서가 없습니다.

-sys 크레이트에는 문서가 없는 것이 일반적입니다(예: openssl-sys ). C에 상응하는 일대일 번역이기 때문입니다. 따라서 C 문서를 직접 검색해야 합니다. 또한 모든 문서를 손으로 복사해야 하므로 또 다른 유지 관리 부담이 가중됩니다. 그래도 기본 문서 페이지에서 https://doc.libelektra.org/api/current/html/index.html 에 연결할 수 있습니다.

어쨌든 elektra-sys는 거의 사용할 수 없는 것 같습니다. Elektra와 관련이 거의 없는 수백 개의 기호를 보여줍니다.

나는 이것을 조사할 것이다.

#2980에서 수정되었으며 다음에 크레이트를 게시할 때 docs.rs에서 수정될 것입니다.

그래도 기본 문서 페이지에서 https://doc.libelektra.org/api/current/html/index.html 에 연결할 수 있습니다.

예, 좋은 생각입니다!