Стандарт описания зависимостей для языка C++
Перенос предложения: голоса +14, -1 Автор идеи: Павел Филонов
Если вместе со стандартом языка будет представлен и формат для описания зависимостей сборки, то это потенциально мотивирует различные менеджеры зависимостей поддержать этот формат, по аналогии с тем, как разработчики компиляторов реализуют стандарт языка.
На данный момент разработчики привыкли к ситуации, что формат описания зависимостей не является частью языка и его стандарта.
Это приводит к тому, что каждый менеджер зависимостей придумывает свой собственный формат. И, на первый взгляд, это не имеет отношение к стандарту языка.
Но, если задуматься, то формат описания зависимостей - это просто формальныеправила, которые определяют синтаксис и семантику, а реализация отдается уже на откуп производителям.
У нас уже есть пример такого подхода - стандарт языка C++. Имеется формальное описание, а разработчики компиляторов уже предлагают свои реализации. Именно такой подход позволяет собирать код, написанный на одном языке, разными компиляторами (с оговорками).
Если вместе со стандартом языка будет представлен и стандарт для описания зависимостей сборки, то это потенциально мотивирует различные менеджеры зависимостей поддержать этот формат, по аналогии с тем, как разработчики компиляторов реализуют стандарт языка.
Из ближайших аналогов подобного описания можно привести в качестве примеров:
- conanfile.txt
- .nuspec
- PEP400
- Cargo
Список открытых вопросов:
- Нужно ли такое описание стандарте? (здесь поможет голосование)
- Какие схемы версионирования нужно поддерживать?
- Какой должен быть синтаксис описания зависимостей?
- Какие ограничения на версии можно накладывать?
Ответы на все эти вопросы требуют детальной проработки материала. Если ответ на
1-й вопрос будет положительным, то можно будет приступить к остальным.
ru.night.beast, 29 марта 2017, 14:00 еще хотелось бы иметь централизованное хранилище пакетов, по типу cpan, ctan etc. тогда бы часть стандартной библиотеки можно было бы переместить туда.
mrgordonfreman, 29 марта 2017, 16:53 ru.night.beast, Такие централизованные хранилища уже есть - репозитории дистрибутивов линукс. А вот чтоб один для всех... И что он будет выдавать? Если исходники, которые будут вытягиваться по описанию зависимостей и собираться локально, то еще как-то можно жить
Сергей Садовников, 29 марта 2017, 17:04 ru.night.beast, в экосистеме С++ слишком большой зоопарк компиляторов, тулчейнов, целевых платформ, способов сборки и т. п., чтобы такой репозиторий мог бы быть эффективно реализован на уровне бинарных пакетов.
ru.night.beast, 29 марта 2017, 17:13 Сергей Садовников, в виде исходников. в зависимостях прописывать для какой системы собирается. наверно возможно добавление и бинарных данных если, опять же, в зависимостях прописать.
Александр Шишенко, 9 августа 2017, 18:24 Сергей Садовников, всё-таки сделали conan-center.
Евгений, 29 марта 2017, 15:41 идея шикарная, но требует детальной проработки, чтобы реализация стала полезной. сейчас проскочила бредовая мысль, что часть этой работы можно было бы поручить препроцессору.
mrgordonfreman, 29 марта 2017, 16:46 Что-то из разряда фантастики. Сначала модули бы получить, без них нет смысла думать о зависимостях.
Pavel, 9 апреля 2017, 23:01 А Гор Нишанов на яндекс.разработке(ютуб) не про это говорил? У них какой-то "vc package" появился (вместо Nuget'a типа).
SG15 Tooling пришли к мысли, что стандартизовать какой-то один пакетный менеджер или инструментарий сборки - не получится. Поэтому сейчас подгруппа сосредоточилась на стандартизации описания зависимостей и флагов сборки, чтобы можно было на этом стандрте описать зависимости и использовать любой пакетный менеджер.