Библиотеки на С слишком сложны. И в этой статье я хочу подробно описать что конкретно под этим имеется в виду и почему оно происходит

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

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

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

Но по какой-то причине в реальности всё совсем не так и тут нужно смотреть на примеры

Типичным примером можно считать репозиторий OpenSSL. Взгляните на (ЧАСТЬ) того что видит перед собой человек, который хочет использовать OpenSSL:

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

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

Раздел "как собрать" обычно состоит из громадного списка if, интерпретировать построчно должны ВЫ, например:

В какой-то момент нужно всё таки вспомнить, что это всего лишь набор .c файлов, которые должны зашифровать байты и расшифровать байты. Откуда здесь взялась эта сложность?

С документацией вообще обычно всё плохо, во многих библиотеках вам предлагают... Скачать репозиторий, собрать его, а потом запустить некий скрипт, который соберёт вам документацию. Да, серьёзно.

Вдумайтесь на секунду, от SSL зависит практически весь мир, эту библиотеку используют все, компании вкладывают в неё ресурсы (если вы задонатили меньше 10'000$ в SSL, то на вас даже не посмотрят), есть примеры "интеграций" от больших компаний, например достаточно взглянуть на главную страницу репозитория и там как минимум есть упоминание cloudflare, упоминаний протокола QUIC от гугла такое множество, будто это библиотека QUIC, а не SSL

Но по видимому ни одна компания так и не решила запросить у openssl ну не знаю там, CMAKELISTS.TXT НАПРИМЕР??? Есть как минимум 3 форка openssl добавляющих поддержку cmake, но все они не поддерживаются - им же не донатят

второй пример

Вот есть популярный аудио кодек OPUS. Им судя по всему пользуются практически все компании в мире. Youtube, AWS, Zoom и тд.

Давайте же взглянем как встречает потенциального пользователя репозиторий opus:

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

Вторая о том как передавать его по сети (там тоже ничего об API)

Третья про сохранение в файл (казалось бы именно это должна делать эта библиотека)

Описание API библиотеки просто отсутствует. В файлах какие-то нейросети, файлы макросов для непонятно чего и даже файл с хеш суммами разных релизов и пустой файл NEWS добавленный 15 лет назад. А вот на документацию файла не нашлось

С билдом также всё стандартно, скрипт который должны исполнить вы:

И ведь там есть CMakeLists.txt - но он представлен как что-то второстепенное и ненужное - вызывайте make и интерпретируйте скрипт вручную!

Также есть целый сайт с документацией, но если вы подумали, что там API библиотеки - вы ошиблись

1. Home - ссылка на страницу с новостями

2. Downloads - страница релизов разных версий (которая и на гитхабе есть)

3. Documentation - ссылка на ЭТУ ЖЕ страницу

4. Presentations/Examples и тд это не как вы могли подумать примеры кода, а примеры файлов записанных библиотекой. Просто музыка, насладиться так сказать библиотекой

И только под ссылкой HTML где-то там лежит API reference, в котором encoder и decoder в сумме на 20 функций, не больше.

Так откуда же в С программистах такая тенденция, чтобы сделать из набора из нескольких .c/.h файлов в сумме на 20 функций такую *** которую невозможно использовать?

Думаю, здесь комплекс факторов. Неправильно считать, что "на С просто нет пакетного менеджера" или что-то такое. Всё у них есть. Проблема в культуре.

Во-первых, чётко наблюдается эффект основателя. Самые большие репозитории на С, они же примеры худших практик, linux и gcc. Собираются только под одну платформу, собираются с трудом, закрытые сообщества - чтобы отправить баг нужно ЛИЧНОЕ знакомство с кем-то из "тусовки", чтобы зарегистрировать аккаунт и отправить письмом сообщение, а чтобы закоммитить придётся по почте отправлять патч и включать личные связи для ревью

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

Для тех, кто считает, что виноват язык, а не люди

Думаю будет всё же много возражений, якобы это язык С вынуждает людей писать всё так плохо.

Тут есть один прекрасный контрпример. Все наслышаны как каждый месяц кто-то в очередной раз запускает DOOM на какой-то очередной железке.
А ведь DOOM это гораздо сложнее перекладывания байт, это целая игра. И я уверен, успешных запусков DOOM было бы в разы меньше, если бы репозиторий DOOM был написан по методичке OpenSSL

Но вот как выглядит репозиторий DOOM:

Как-то обошлись только необходимым, без тонн мусора на странице. Буквально только .c/.h файлы и несколько файлов readme документации

Но всё же, для меня так и остаётся загадкой, почему авторы библиотек на С вкладывают так много казалось бы ресурсов в создание библиотеки и её поддержку, а потом делают ей такую обёртку, что использовать библиотеку становится проблематично, а то и невозможно