Comments 14
Интересно, цэпэпэ может похвастаться таким набором фич?
Я бы сказал что в целом да, хотя надо немного больше усилий потратить.
Инструменты типа Homu, Clog и подобное вообще от языка не зависят. Readme.md и лицензия тоже. Travis почти так же прикручивается.
Статических анализаторов для плюсов много (сравнение эффективности этих анализаторов с встроенными и внешними проверками ржавчины, это немного другой вопрос).
Автогенерация и автозагрузка куда-то там документации, при желании, тоже делается в том же трэвисе.
Для автоформатирования есть clang-format и еще много всякого.
Тесты, хоть и не вшиты в язык, тоже никто не запрещает делать. Какие-то инструменты для сбора информации о тестовом покрытии тоже есть.
Так что из существенного остается, как мне кажется, только Cargo и его метаданные — у плюсов нет стандартного менеджера пакетов и центрального хранилища.
Инструменты типа Homu, Clog и подобное вообще от языка не зависят. Readme.md и лицензия тоже. Travis почти так же прикручивается.
Статических анализаторов для плюсов много (сравнение эффективности этих анализаторов с встроенными и внешними проверками ржавчины, это немного другой вопрос).
Автогенерация и автозагрузка куда-то там документации, при желании, тоже делается в том же трэвисе.
Для автоформатирования есть clang-format и еще много всякого.
Тесты, хоть и не вшиты в язык, тоже никто не запрещает делать. Какие-то инструменты для сбора информации о тестовом покрытии тоже есть.
Так что из существенного остается, как мне кажется, только Cargo и его метаданные — у плюсов нет стандартного менеджера пакетов и центрального хранилища.
Мы как раз используем clang-format и, в принципе, всё хорошо. Правда некоторые макросы он уродовал и с Boost.Assignment какие-то проблемы были. Причём на тот момент какого-то простого способа для отключения форматирования на куске кода не нашлось. В итоге пришлось подстраиваться. Думаю, что растовый формат должен получше справляться со сложными конструкциями языка.
Cargo — для плюсов это больной вопрос. (:
Ну и не совсем по теме, но "зато" в плане IDE и, наверное, профайлеров расту ещё надо догонять...
Cargo — для плюсов это больной вопрос. (:
Ну и не совсем по теме, но "зато" в плане IDE и, наверное, профайлеров расту ещё надо догонять...
В качестве пакетного менеджера для плюсов можно использовать нестандартный biicode.
Да их для плюсов, как и систем сборки (хотя тут, вроде, cmake доминирует), много. В этом и проблема :(
А есть что-то по крайней мере достаточно хорошее? Вон внизу подсказывают, что biicode уже слился.
Как по мне, так единственный заслуживающий внимания «пакетный менеджер» для плюсов — это Find-модули CMake. В принципе, этого могло быть достаточно, если бы на всех популярных платформах был нормальный системный пакетный менеджер. А сейчас лично мне непонятно, какие именно задачи должен решать системный PM, а какие — PM для языка и его экосистемы.
единственный заслуживающий внимания «пакетный менеджер» для плюсов — это Find-модули CMake
Склонен согласиться, к сожалению
В принципе, этого могло быть достаточно, если бы на всех популярных платформах был нормальный системный пакетный менеджер.
Смотря какие требования. Возможности далеко не всех системных ПМ удобны для разработки, они все-таки на администраторов/пользователей заточены.
лично мне непонятно, какие именно задачи должен решать системный ПМ, а какие — ПМ для языка и его экосистемы
Я для себя разделение довольно четко вижу: системный ПМ — установка уже готовых программ (ИМХО, в системном ПМ вообще не должно быть команды "поставить библиотеку", только "поставить программу"), языкоспецифичный ПМ — установка всяких зависимостей для разработки чего-то там.
Соглашусь насчёт менеджеров.
Вот, кстати, неплохая статья об их разновидностях и особенностях: https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527#.agfs5x9q8
Вот, кстати, неплохая статья об их разновидностях и особенностях: https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527#.agfs5x9q8
Мне кажется, что "поставить библиотеку" — вещь все-таки нужная, когда речь идёт о зависимостях. Правильную библиотеку, при обнаружении в ней неприятного косяка (допустим, в какой-нибудь libpng, которую использует треть софта в системе), легко обновить, если системный ПМ сам разруливает зависимости. Иначе, когда весь софт идёт монолитным пакетом, то и обновлять надо каждую программу отдельно. За примером далеко ходить не надо — Windows Installer в зависимости не умеет (а хочется), и в итоге разработчики декстопного софта кладут dll-ки всяких C++ runtime прямо в каталог приложения, чтобы было проще деплоить. При этом, сам MS рекомендует ставить рантаймы официальным инсталлятором, чтобы они были отдельными пакетами в системе и их можно было обновить отдельно.
Я в целом согласен, что системный ПМ — это что-то про готовые, "релизные" версии ПО. Конечному пользователю не нужно (и даже вредно в случае серверного ПО) ставить что-то, относящееся к разработке — include-ы/lib-ы, дебажные версии и т.д. Но сразу же возникает ряд вопросов и тонких моментов:
Кто (системный/языковой ПМ) должен ставить include/lib? А отладочные символа? А дебажные версии dll/so?
Допустим, что системный ПМ ставит только релизные бинарники, и больше ничего. Значит, бинарниками и прочими вещами для разработки должен заведовать языковой ПМ. А он справится с этим? Системный тем и хорош, что учитывает особенности конкретного семейства ОС или даже дистрибутива. Значит, придется наш C++ Package Manager учить разбираться и в PE/ELF, и в различных архтектурах?
Допустим, что ЛЮБЫЕ нативные бинарники мы ставим системным ПМ, а языковой ПМ занимается только специфичными для языка аспектами — например, инклудами в случае C++, или биндингами к более высокоуровневым языкам, или самим исходным кодом библиотеки. Казалось бы, неплохой вариант. Например, header-only библиотеки жили бы только в языковом ПМ, а библиотеки с компилируемым кодом подтягивались бы еще и системным. Но тогда как это всё увязать? Ссылаться из языкоспецифичного пакета на системный? А получится ли это сделать кроссплатформенно? Что делать с Виндой, где вроде бы как есть системный ПМ, но используется он для установки монолитных "продуктов" а-ля "Фотошоп 2015", а не для приложения с деревом зависимостей?
Я в целом согласен, что системный ПМ — это что-то про готовые, "релизные" версии ПО. Конечному пользователю не нужно (и даже вредно в случае серверного ПО) ставить что-то, относящееся к разработке — include-ы/lib-ы, дебажные версии и т.д. Но сразу же возникает ряд вопросов и тонких моментов:
Кто (системный/языковой ПМ) должен ставить include/lib? А отладочные символа? А дебажные версии dll/so?
Допустим, что системный ПМ ставит только релизные бинарники, и больше ничего. Значит, бинарниками и прочими вещами для разработки должен заведовать языковой ПМ. А он справится с этим? Системный тем и хорош, что учитывает особенности конкретного семейства ОС или даже дистрибутива. Значит, придется наш C++ Package Manager учить разбираться и в PE/ELF, и в различных архтектурах?
Допустим, что ЛЮБЫЕ нативные бинарники мы ставим системным ПМ, а языковой ПМ занимается только специфичными для языка аспектами — например, инклудами в случае C++, или биндингами к более высокоуровневым языкам, или самим исходным кодом библиотеки. Казалось бы, неплохой вариант. Например, header-only библиотеки жили бы только в языковом ПМ, а библиотеки с компилируемым кодом подтягивались бы еще и системным. Но тогда как это всё увязать? Ссылаться из языкоспецифичного пакета на системный? А получится ли это сделать кроссплатформенно? Что делать с Виндой, где вроде бы как есть системный ПМ, но используется он для установки монолитных "продуктов" а-ля "Фотошоп 2015", а не для приложения с деревом зависимостей?
Не стоит, biicode уже свёрнут. Вот что бывает, когда проект не open source.
Однако есть открытый аналог — conan. Пока вроде пилят активно.
Однако есть открытый аналог — conan. Пока вроде пилят активно.
Sign up to leave a comment.
Советы по написанию библиотек на Rust