ideas icon indicating copy to clipboard operation
ideas copied to clipboard

Стандарт описания зависимостей для языка C++

Open apolukhin opened this issue 4 years ago • 2 comments

Перенос предложения: голоса +14, -1 Автор идеи: Павел Филонов

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

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

Это приводит к тому, что каждый менеджер зависимостей придумывает свой собственный формат. И, на первый взгляд, это не имеет отношение к стандарту языка.

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

У нас уже есть пример такого подхода - стандарт языка C++. Имеется формальное описание, а разработчики компиляторов уже предлагают свои реализации. Именно такой подход позволяет собирать код, написанный на одном языке, разными компиляторами (с оговорками).

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

Из ближайших аналогов подобного описания можно привести в качестве примеров:

  • conanfile.txt
  • .nuspec
  • PEP400
  • Cargo

Список открытых вопросов:

  • Нужно ли такое описание стандарте? (здесь поможет голосование)
  • Какие схемы версионирования нужно поддерживать?
  • Какой должен быть синтаксис описания зависимостей?
  • Какие ограничения на версии можно накладывать?

Ответы на все эти вопросы требуют детальной проработки материала. Если ответ на

1-й вопрос будет положительным, то можно будет приступить к остальным.

apolukhin avatar Mar 23 '21 16:03 apolukhin

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 типа).

apolukhin avatar Mar 23 '21 16:03 apolukhin

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

apolukhin avatar Oct 23 '23 08:10 apolukhin