Libelektra: Наручники из ржавчины

Я мало что знаю о Rust, но полагаю, что привязки, сгенерированные rust-bindgen могут использоваться только в unsafe Rust? Если это так, было бы неплохо иметь оболочку для тех, у кого более идиоматичный Rust API.

AFAIK у большинства привязок Rust есть один ящик *-sys для сопоставления 1: 1 C API и другой ящик с API, который большинство пользователей фактически использовали бы в Rust. Если есть способ указать 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. Файл докеров Debian Buster еще не объединен # 2819

Я полагаю, что нет автоматического способа сделать это.

Для этого есть несколько идей: # 730

Rust-bindgen предлагает два способа создания привязок. Один из них - через командную строку, поэтому это ручной процесс, который необходимо повторить, если что-то в C-API изменится. Другой - через скрипт сборки, который запускается каждый раз, когда запускается сборка Cargo. Это означает, что привязки регенерируются при каждой сборке. Это то, что сейчас реализовано. Однако он требует, чтобы у всех, кто использует привязки, были необходимые заголовки, которые нужны elekra. Я полагаю, если кто-то просто установит elektra, но не скомпилировал его, он может не соответствовать всем необходимым требованиям. Может быть, имеет смысл периодически обновлять заголовки вручную, поскольку C-API больше не сильно меняется?

Регенерация в каждой сборке кажется правильным решением, другие привязки также работают таким же образом (они требуют установки swig). Вы можете просто установить сгенерированные файлы заголовков, чтобы избежать проблем, которые вы описываете.

Да, это план. И при этом также сравните с C API и, возможно, найдете улучшения в C API (по крайней мере, в документе).

Пока что я нашел несколько незначительных возможностей для улучшения

• keyGetBinary : Как код вызова, я не могу знать, означает ли возвращаемое значение -1 maxSize is 0 или type mismatch или что-то еще. Поскольку Rust использует явную обработку ошибок в своих возвращаемых аргументах, я хотел бы иметь возможность сопоставлять несоответствие типа с ошибкой, а ошибки, связанные с maxSize, с другими. Но в настоящее время я должен использовать более общую ошибку. Я мог бы сам проверить наличие несоответствия типов, но keyGetBinary делает это, так что я делаю одну и ту же проверку дважды.
  keySetName делает нечто подобное, сопоставляя две разные ошибки с -1. В обоих случаях есть ошибки, которые являются ошибками (неверное имя) и ошибками, которые могут возникать в звуковых программах (ключ уже в наборе ключей), поэтому я могу как бы понять решение. Но почему бы не использовать -2 для ясности и предотвращения двойной проверки?
• Грамматически, не должно ли keyIsDirectBelow быть keyIsDirectlyBelow 🙂? Если да, следует ли мне исправить это в Rust API?

Другой вопрос: keyRel не реализовано в привязках CPP. Должен ли я пропустить это и в Rust?

Отличная работа, из ваших вопросов очевидно, что вы уже глубоко заглянули в API.

Я мог бы сам проверить несоответствие типов, но keyGetBinary делает это, поэтому я дважды выполняю одну и ту же проверку.

Может быть, вы даже можете использовать систему типов, чтобы избежать неправильных вызовов? (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 as-is не работает и работает медленно. Так что, скорее всего, мы удалим его в пределах 0.9. См. Doc / todo / FUTURE для удаления других кандидатов.

Может быть, вы даже можете использовать систему типов, чтобы избежать неправильных вызовов? (keyGetBinary разрешен только для двоичных ключей)

Это отличная идея. Я мог бы иметь BinaryKey и StringKey и только у первого был бы метод get_binary() и только у второго был бы метод get_string() , и так далее. Я займусь этим.

Вы хотите исправить эти проблемы с API?

Я могу это сделать. Зависит от того, какой для меня приоритет. Завершив разработку безопасного API для Rust, вы сказали, что было бы неплохо иметь и API плагинов в Rust. Вы можете решить, что важнее.

Это отличная идея. Я мог бы иметь BinaryKey и StringKey, и только у первого был бы метод get_binary (), и только у второго был бы метод get_string (), и так далее. Я займусь этим.

Спасибо. Может потребоваться слишком много приведений, так что давайте посмотрим, хорошая ли это идея. Также другой тип может быть полезен для ключей в наборах ключей (где setName не допускается).

Я могу это сделать. Зависит от того, какой для меня приоритет. Завершив разработку безопасного API для Rust, вы сказали, что было бы неплохо иметь и API плагинов в Rust. Вы можете решить, что важнее.

Да, сначала доработайте Rust API с kdb.h, а потом посмотрим, сколько еще часов нам нужно потратить.

IMO привязка Rust (и любая привязка в этом отношении) должна иметь две версии. Один, максимально приближенный к C API, и другой, более идиоматичный для языка, основанного на первой версии. В идиоматической версии использование системы типов с BinaryKey и StringKey (или даже дженерики), вероятно, является хорошей идеей, если это упрощает использование API из Rust.

@kodebach Согласен. И, похоже, это также сделано с ящиками elektra и elektra-sys.

@kodebach Согласен. И, похоже, это также сделано с ящиками elektra и elektra-sys.

Да, я тоже так думаю. Если у безопасного Rust API есть ограничения, которые необходимо обойти, можно импортировать elektra_sys и напрямую вызвать функцию привязки C.

Спасибо. Может потребоваться слишком много приведений, так что давайте посмотрим, хорошая ли это идея. Также другой тип может быть полезен для ключей в наборах ключей (где setName не допускается).

Это отлично сработало для ключевой реализации. Однако для KeySets я наткнулся на препятствие. Для любых методов, возвращающих ключ, он должен соответствовать общему интерфейсу, который я создал. Я реализовал метод get_value который имеет общий возвращаемый параметр. Для BinaryKeys это байты, для StringKeys - строки. Но что теперь возвращает ржавая версия ksNext ? Объект, удовлетворяющий «ключевому интерфейсу», но с каким значением? Я должен выбрать один.
Так должна выглядеть подпись, где Value - это тип, возвращаемый get_value . Я могу указать только байты ( Vec<u8> ) или String.
pub fn next(&mut self) -> Box<dyn WriteableKey<Value = Vec<u8>>>;

Таким образом, я мог бы объединить его в байты, но тогда пользователь должен сам преобразовать в строку. Поскольку единственное различие StringKey и BinaryKeys заключается в их реализации set_value и get_value , это изменение удалит эту явность, и у меня снова остались только ключи.

Я предполагаю, что настоящая проблема в том, что KeySet в текущей реализации не указывает явно, какие ключи он содержит, а ключи * есть. Но разрешить экземпляру KeySet содержать только StringKey или BinaryKey, я полагаю, является слишком большим ограничением.
Я думаю, что и Key, и KeySet должны четко указывать, что они содержат, или ни одного из них. Сейчас я склоняюсь к общим Key и KeySet, просто чтобы соответствовать остальной части elektra.
Есть предположения?

С точки зрения удобства использования имеет смысл возвращать Key, у которого есть геттер для String, так как это наиболее часто используемый вариант. Сеттер для имени должен быть отключен (если это легко возможно), поскольку мы уже знаем, что этот ключ (возвращаемый next) является частью KeySet.

В общем, система шрифтов должна поддерживать пользователя, а не мешать ему. Так что делайте это как можно проще. Наиболее частые ошибки:

1. пытается изменить имя ключа на ключ в наборе ключей.
2. пытается изменить ключи метаданных (или другие константные ключи).
3. непонятное дублирование Key / KeySet и ссылок на них.
4. итерация по KeySets, которые также используются для вырезания ключей таким образом, что итерация больше не работает правильно.
5. забыли освободить ключ / набор ключей

Так что, если бы здесь могла помочь система типов, было бы здорово. 5. Будем надеяться, что это невозможно по дизайну, для 1. и 2. ваша абстракция должна помочь.

Путаница между двоичными и строковыми кодами на самом деле является довольно редкой ошибкой (потому что двоичные ключи очень нетипичны: они в основном используются для хранения указателей на функции).

Кстати. если вы хотите написать проектное решение о безопасном использовании API, продолжайте (документ / решение)

С точки зрения удобства использования имеет смысл возвращать Key, у которого есть геттер для String, так как это наиболее часто используемый вариант.

Но не каждая байтовая последовательность действительна в кодировке UTF-8, так что она больше не будет типизированной, не так ли?

Насколько я знаю, макросистема в Rust очень мощная, возможно, есть способ написать функцию, которая всегда возвращает правильный тип. Например, в Kotlin есть метод для карт для кодирования типа значения в ключе. Ссылка на API

В качестве альтернативы может иметь смысл StringKeySet который принимает только StringKey s, поскольку двоичные ключи настолько редки и в основном не используются в конфигурациях.

С точки зрения удобства использования имеет смысл возвращать Key, у которого есть геттер для String, так как это наиболее часто используемый вариант. Сеттер для имени должен быть отключен (если это легко возможно), поскольку мы уже знаем, что этот ключ (возвращаемый next) является частью KeySet.

Но все же возможно, хотя и редко, иметь KeySet со смешанными ключами. Тогда всегда возвращать StringKey и вызывать get_string было бы ошибкой, но система типов не только позволяет это, но и направляет вас к ней, поскольку для этого типа нет метода get_binary .

Прежде чем сделать это, я предлагаю сделать KeySet универсальным и создать его экземпляр как KeySet<StringKey> если пользователь уверен, что внутри есть только StringKeys (для тех KeySet, не исходящих от Rust). Тогда вполне естественно, что итерация по нему даст только StringKeys.
Это также потребовало бы, чтобы KeySets были однородными через систему типов, по крайней мере, те, которые были созданы пользователями Rust, что было бы в целом более безопасным.
В редких случаях, когда ожидается двоичный ключ, пользователю придется проверить с помощью is_binary и is_string а затем преобразовать, что было бы безопасным вызовом метода.

непонятное дублирование Key / KeySet и ссылок на них.

Я думаю, единственное, что я могу сделать, - это продвигать использование дубликатов, а не счетчиков ссылок. Это может быть хуже для производительности, но keyDel вызывается Rust автоматически, а подсчет ссылок полностью выполняется вручную. Так что дублирование, безусловно, легче исправить, чем подсчет ссылок.

итерация по KeySets, которые также используются для вырезания ключей таким образом, что итерация больше не работает правильно.

Вы имеете в виду изменение набора ключей во время итерации по нему?

Кстати. если вы хотите написать проектное решение о безопасном использовании API, продолжайте (документ / решение)

Каково будет содержание этого?

Насколько я знаю, макросистема в Rust очень мощная, возможно, есть способ написать функцию, которая всегда возвращает правильный тип.

Я думаю, что «текущий» дизайн KeySet, который может содержать что угодно и конкретные типы ключей, не работает вместе, по крайней мере, не очень хорошо. Но я поищу макросы.

Но не каждая байтовая последовательность действительна в кодировке UTF-8, так что она больше не будет типизированной, не так ли?

Ни строки, ни двоичное значение Elektra не должны быть в кодировке UTF-8. Elektra делает выбор только между строкой и двоичным кодом (может содержать 0 байтов).

Насколько я знаю, макросистема в Rust очень мощная, возможно, есть способ написать функцию, которая всегда возвращает правильный тип. Например, в Kotlin есть метод для карт для кодирования типа значения в ключе. Ссылка на API здесь является примером.

Нам также нужно следить за тем, чтобы прилагать усилия к созданию полезных функций. Бинарные ключи встречаются редко.

В качестве альтернативы может иметь смысл StringKeySet, который принимает только StringKeys, поскольку двоичные ключи настолько редки и в основном не используются в конфигурациях.

Да, но я бы увидел StringKeySet как обычный KeySet.

Но все же возможно, хотя и редко, иметь KeySet со смешанными ключами. Тогда всегда возвращать StringKey и вызывать get_string было бы ошибкой, но система типов не только позволяет это, но и направляет вас к ней, поскольку для этого типа нет метода get_binary.

Да, но, как уже было сказано, это небольшая проблема. Люди, которые хранят двоичные данные (например, адреса функций), узнают, как преобразовать ключ (если есть какой-то документ об этом).

Перед этим я предлагаю сделать KeySet универсальным и создать его экземпляр как KeySet.если пользователь уверен, что внутри есть только StringKeys (для тех KeySets, не исходящих от Rust). Тогда вполне естественно, что итерация по нему даст только StringKeys.

Это была бы только фальшивая безопасность, потому что KeySets поступают из KDB (извне) и в любом случае могут содержать двоичные данные. Поэтому я предпочитаю иметь не общий набор ключей.

Если вы хотите поиграть с универсальными шаблонами, предоставьте средства получения и установки, которые преобразуют наборы ключей в (общие) структуры данных. Например, массив Elektra целых чисел до Vec<i32> .

Вы имеете в виду изменение набора ключей во время итерации по нему?

Да cut изменяет KeySet. В целом итераторы безопасны для этого, но у многих возникают проблемы с их правильным выполнением.

Каково будет содержание этого?

Краткое изложение того, что мы здесь обсуждаем, и того, как вы это разработали.

Я думаю, что «текущий» дизайн KeySet, который может содержать что угодно и конкретные типы ключей, не работает вместе, по крайней мере, не очень хорошо.

Я согласен.

Но я поищу макросы.

Пожалуйста, не ставьте это в приоритет.

Ни строки, ни двоичное значение Elektra не должны быть в кодировке UTF-8.

Затем мы должны использовать OsString или CString вместо String согласно быстрому поиску.

Ни строки, ни двоичное значение Elektra не должны быть в кодировке UTF-8.

Затем мы должны использовать OsString или CString вместо String согласно быстрому поиску.

Прямо сейчас я конвертирую Rust String (это UTF-8) в CString перед тем, как передать его elektra. Обоснование состоит в том, что String - это строка по умолчанию, и большинство других библиотек рассчитывают работать с ней.
Вместо этого я могу заставить высокоуровневый API запрашивать и возвращать CString s, чтобы пользователю приходилось иметь дело с кодом преобразования, если ему нужен String . Это сделало бы API более тонким и уменьшило бы обработку ошибок, с которой нужно было иметь дело. Я предполагаю, что все сводится к тому, как большинство пользователей захотят использовать API, в котором я не очень разбираюсь.

Я согласен с тем, что лучше всего вернуть наиболее распространенный тип String для языков. Строки, отличные от UTF8, должны быть редкими (возможно, даже более редкими, чем двоичные файлы).

Я согласен с тем, что лучше всего вернуть наиболее распространенный тип String для языков. Строки, отличные от UTF8, должны быть редкими (возможно, даже более редкими, чем двоичные файлы).

Я пытаюсь найти лучший способ справиться с направлением Rust -> C, переходя от UTF-8 к C-строке. Строки UTF-8 могут содержать нулевые байты, но единственная кодовая точка, где это появляется, - это символ NUL, а не иначе . Я думаю, что было бы разумно указать это как предварительное условие в документации по привязке, что строки не могут содержать нулевой байт. Если это все равно произойдет, код паникует в этот момент.

Другая возможность - вернуть ошибку из всех установленных функций, которые принимают строку. Но тогда пользователям приходится иметь дело с этим NulError все время, и он практически никогда не возвращается.

keyNew может вернуть нулевой указатель при ошибке распределения. В Rust я могу либо возвращать явные ошибки, либо панику, но не неявный нуль. В документе rust по ошибкам сигнализации нехватка памяти рассматривается как катастрофическая ошибка, и в этом случае stdlib abort s. Привязка java, похоже, не обрабатывает этот случай, поэтому я предполагаю, что она также выйдет из процесса, поскольку выдается NullPointerException .
Согласны ли вы, что здесь лучше всего вызывать панику (прерывание не позволяет запускать деструкторы)?

Я думаю, что было бы разумно указать это как предварительное условие в документации по привязке, что строки не могут содержать нулевой байт. Если это все равно произойдет, код паникует в этот момент.

Да, разумно.

Согласны ли вы, что здесь лучше всего вызывать панику (прерывание не позволяет запускать деструкторы)?

Да, есть смысл паниковать, если malloc вышел из строя. (В случае Rust как stdlib будет делать то же самое. В C stdlib не прерывается, поэтому C-Elektra также не прерывает работу).

Теперь, когда привязки Rust объединены в мастер, я хотел бы опубликовать их на crates.io.
Я предлагаю публиковать их с версией, установленной на (по умолчанию) 0.1.0 , вместо того, чтобы быть привязанными к elektra, просто потому, что степень зрелости привязок и сама elektra различаются. Вы согласны с @ 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 ). Поэтому я должен явно указать clang включить /usr/include/elektra чтобы он начал сборку.
Всегда ли elektra устанавливается в /usr/include/elektra чтобы это решение работало для большинства дистрибутивов?

Всегда ли elektra устанавливается в / usr / include / elektra, чтобы это решение работало для большинства дистрибутивов?

Да, потому что есть другая библиотека (я думаю, от Kerberos), которая использует /usr/include/kdb.h .

На данный момент /usr/include/elektra должен быть частью пути включения, но, НАСКОЛЬКО, мы хотим изменить это так, чтобы вместо него можно было использовать #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 в свои зависимости, и cargo получит ящик 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 и использовать предоставленные includeir. В противном случае он будет искать в двух названных вами каталогах.

Привязки опубликованы: elektra и elektra-sys : smiley:

Из-за отсутствия системной зависимости libelektra в среде сборки docs.rs документация не была построена. Кроме того, 30 сентября они изменят среду сборки.
Я отправил запрос на добавление libelektra в качестве зависимости, чтобы она правильно построилась 30 сентября. Он также добавил пакет к существующей среде, поэтому документы теперь доступны: +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 на главной странице документа.

Да, хорошая идея!