Здравствуйте, Reset, Вы писали:

R>Пакетные менеджеры в C++ есть и ими нужно пользоваться.

На мой взгляд менеджеры пакетов, глобальные репозитории языка и т.п. — это не нужная часть инфраструктуры. Т.е. она конечно же никому не мешает, так что я совершенно не против неё. Просто не вижу в ней никакого смысла (какая разница откуда скачать библиотеку, из некого единого сайта или от её создателей. Вообще говоря создателям я обычно доверяю больше чем неким мейнтейнерам). В отличие от менеджеров зависимостей! Это совершенно другой инструмент и вот уже он реально необходим в современном языке. В некоторых современных языках есть инструменты объединяющие эти две разные функциональности в единый инструмент разработчика (типа cargo, который и собирает с зависимостями и качает с глобального репозитория), но это не значит что так надо делать всегда. Особенно в таком сложном и глобальном случае, как с C/C++.

Здравствуйте, alex_public, Вы писали:

_>Вообще то уже давно есть и на голову превосходящий.

Имя, сестра, имя!

Здравствуйте, Nuzhny, Вы писали:

_>>Ну а вообще, если твои пользователи готовы ради твоей библиотечки научиться чему-то не самому попсовому, то можно просто использовать настоящую современную систему сборки с отслеживанием всех зависимостей. Благо такая уже лет пять как появилась в мире C++ (причём она ещё и наголову мощнее всех этих maven'ов и т.п.). И единственный её недостаток в том, что широкие массы хомячков от программирования пока не научились с ней работать.
N>Что же это за среда? Ни vcpkg, ни Conan далеко не идеальны и требуют костылей.

Не, я не про эти убогие попытки написать глобальный репозиторий библиотек на C/C++ (думаю что это вообще нереальная и не нужная задача). Я именно про систему сборки с учётом зависимостей (ну и да, если ты это укажешь, то она может и скачать зависимость с гитхаба, но это мелкая побочная функциональность). И такая система для C++ сейчас есть одна: bazel (https://bazel.build). Формально она конечно же универсальная, а не только под C++, но если залезть внутрь, то хорошо видно, что она вся создавалась именно с прицелом на построение больших C++ проектов с кучей зависимостей от разных библиотек и с одновременной сборкой под разные целевые платформы. После знакомства с ней я уже даже не представляю как раньше мог пользоваться всеми этими кривыми пародиями на систему сборки, типа CMake/SCons/Meson и т.п., в которых даже не формализировано такое понятие как целевая архитектура (триплет) и настройки опций под каждую из них, я уже не говорю про формализацию тулчейнов и их мгновенное переключение для всего проекта (включая перестройку зависимостей). Но главное — это конечно же полный контроль над зависимостя. И возможность выкачать исходники из инета (включая указание ревизии на гитхабе или хэш zip архива) — это лишь мелкая и не принципиальная (лично меня не напрягало бы и отсутствие такое возможности, т.к. это всего один клик в браузере) функциональность. Главное же начинается, когда исходники уже скачены и надо это всё собрать под десяток платформ...

P.S. Естественно в технической дискуссии аргумент про миллион продвинутых мух не является особо значимым. Но если что, bazel — это то, что использует Гугл внутри себя для своих C++ проектов.

Здравствуйте, so5team, Вы писали:

_>>Вообще то уже давно есть и на голову превосходящий.
S>Имя, сестра, имя!

Ответил выше. )

Здравствуйте, alex_public, Вы писали:

_>И такая система для C++ сейчас есть одна: bazel (https://bazel.build).

А как там делается кастомизация под конкретные условия? Ну типа, если у нас такая-то платформа и такой-то компилятор, то нужно определить вот такой-вот define и добавить компилятору и линкеру таких-то опций?

Вопрос не праздный, ибо много бодался со сборкой C++ проектов и, по итогу, оказывалось, что системам сборки нужно иметь собственный скриптовый язык (как в CMake) или базироваться на существующих языках (как SCons).

Кроме того, Conan не заставляет использовать централизованный репозиторий. Можно применять и кучу частных репозиториев.
Но так уж получается, что для новичков проще, когда есть какой-то один централизованный репозиторий (типа conan-central), в котором можно быстро найти нужное.

Здравствуйте, alex_public, Вы писали:

_>Не, я не про эти убогие попытки написать глобальный репозиторий библиотек на C/C++ (думаю что это вообще нереальная и не нужная задача). Я именно про систему сборки с учётом зависимостей (ну и да, если ты это укажешь, то она может и скачать зависимость с гитхаба, но это мелкая побочная функциональность). И такая система для C++ сейчас есть одна: bazel (https://bazel.build). Формально она конечно же универсальная, а не только под C++, но если залезть внутрь, то хорошо видно, что она вся создавалась именно с прицелом на построение больших C++ проектов с кучей зависимостей от разных библиотек и с одновременной сборкой под разные целевые платформы. После знакомства с ней я уже даже не представляю как раньше мог пользоваться всеми этими кривыми пародиями на систему сборки, типа CMake/SCons/Meson и т.п., в которых даже не формализировано такое понятие как целевая архитектура (триплет) и настройки опций под каждую из них, я уже не говорю про формализацию тулчейнов и их мгновенное переключение для всего проекта (включая перестройку зависимостей). Но главное — это конечно же полный контроль над зависимостя. И возможность выкачать исходники из инета (включая указание ревизии на гитхабе или хэш zip архива) — это лишь мелкая и не принципиальная (лично меня не напрягало бы и отсутствие такое возможности, т.к. это всего один клик в браузере) функциональность. Главное же начинается, когда исходники уже скачены и надо это всё собрать под десяток платформ...

Ну, я им пользовался, когда собирал Tensorflow. По итогу оказалось проще взять с Гитхаба репозиторий, который представляет собой обёртку на CMake над Basel. Оказалось проще так.

Здравствуйте, so5team, Вы писали:

_>>И такая система для C++ сейчас есть одна: bazel (https://bazel.build).
S>А как там делается кастомизация под конкретные условия? Ну типа, если у нас такая-то платформа и такой-то компилятор, то нужно определить вот такой-вот define и добавить компилятору и линкеру таких-то опций?

Ну вот прямо так и пишешь:

cc_binary(
    name = "mybinary",
    srcs = ["main.cc"],
    copt = select({
        ":arm": ["-DARM", "-DXAXA"],
        ":x86_my_x_debug": ["-Dx86", "-DXIXI"],
        "//conditions:default": ["-DXREN_KAKAYA_TO"],
    }),
)

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

S>Вопрос не праздный, ибо много бодался со сборкой C++ проектов и, по итогу, оказывалось, что системам сборки нужно иметь собственный скриптовый язык (как в CMake) или базироваться на существующих языках (как SCons).

В bazel как раз свой язык Starlark (https://github.com/bazelbuild/starlark), который по факту просто встроенный Python с некими минимальными ограничениями.

Но! Систем сборки с полноценным внутренним языком уже и так полно (например я когда-то пользовался waf — более быстрым наследником SCons). Надо наоборот, чтобы был декларативный способ задать все зависимости. Но при этом не доходя до крайностей типа только такого способа (как в Maven с их убогим xml), т.к. это тоже неудобно. В bazel мне кажется находится разумный компромисс между этими двумя подходами. В целом такое же можно было сделать и из SCons/Waf, написав на их внутреннем языке горы кода, создающего и обрабатывающего все эти декларативные структуры. Но у меня что-то не было желания это делать самому. Это уже не говоря о том, что эта моя поделка в любом случае не могла бы стать стандартом, применяемым во всём мире.

S>Кроме того, Conan не заставляет использовать централизованный репозиторий. Можно применять и кучу частных репозиториев.
S>Но так уж получается, что для новичков проще, когда есть какой-то один централизованный репозиторий (типа conan-central), в котором можно быстро найти нужное.

Лично я не представляю зачем может понадобиться в таком языке как C++ (с его бесчисленными опциями компилятору, меняющими вообще всё, включая до полной несовместимости) распространение БИНАРНЫХ пакетов. Это бред, который вот разве что новичкам и может быть интересен, для более быстро написания "hello world".

Здравствуйте, Nuzhny, Вы писали:

N>Ну, я им пользовался, когда собирал Tensorflow. По итогу оказалось проще взять с Гитхаба репозиторий, который представляет собой обёртку на CMake над Basel. Оказалось проще так.

Если тебе надо один раз собрать одну библиотеку под одну платформу, то безусловно cmake удобнее. ))) Но вот если тебе надо постоянно собирать большой проект, зависящий от десятков библиотек, под пяток платформ, то ничего сравнимого с bazel ты не найдёшь.

Здравствуйте, alex_public, Вы писали:

_>Лично я не представляю зачем может понадобиться в таком языке как C++ (с его бесчисленными опциями компилятору, меняющими вообще всё, включая до полной несовместимости) распространение БИНАРНЫХ пакетов. Это бред, который вот разве что новичкам и может быть интересен, для более быстро написания "hello world".

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

Здравствуйте, alex_public, Вы писали:

_>Ну вот прямо так и пишешь:
_>

_>cc_binary(
_>    name = "mybinary",
_>    srcs = ["main.cc"],
_>    copt = select({
_>        ":arm": ["-DARM", "-DXAXA"],
_>        ":x86_my_x_debug": ["-Dx86", "-DXIXI"],
_>        "//conditions:default": ["-DXREN_KAKAYA_TO"],
_>    }),
_>)
_>

Чесно говоря, выглядит убого. Например, я у себя могу проверить, есть ли файлик local-build.rb, если есть по подгрузить его. А в local-build.rb могут быть вещи типа:

if 'gcc' == toolset.name && RUNTIME_DEBUG == runtime_mode
  global_compiler_option '-fsanitize=address'
  global_compiler_option '-fno-omit-frame-pointer'
  global_linker_option '-fsanitize=address'
end

И это все не будет мешаться в описании проекта, поскольку касается только конкретной сборки на конкретной машине.

_>В bazel как раз свой язык Starlark (https://github.com/bazelbuild/starlark), который по факту просто встроенный Python с некими минимальными ограничениями.

Как-то репозиторий выглядит не сильно живым для языка, который типа должен использоваться активно.

Я это к тому, что для C++ мира вне Google bazel выглядит маргинально, к сожалению.

_>Но! Систем сборки с полноценным внутренним языком уже и так полно (например я когда-то пользовался waf — более быстрым наследником SCons). Надо наоборот, чтобы был декларативный способ задать все зависимости.

Ну вот чистой декларативщины не хватает. И нужен язык. Причем хотелось бы не такой убогий, как в CMake.

_>Лично я не представляю зачем может понадобиться в таком языке как C++ (с его бесчисленными опциями компилятору, меняющими вообще всё, включая до полной несовместимости) распространение БИНАРНЫХ пакетов. Это бред, который вот разве что новичкам и может быть интересен, для более быстро написания "hello world".

Многим нравится, что из Conan-а можно забирать готовые Boost-ы, ICU, imagemagick и пр. без необходимости компилировать их у себя на машине.

Здравствуйте, Nuzhny, Вы писали:

_>>Лично я не представляю зачем может понадобиться в таком языке как C++ (с его бесчисленными опциями компилятору, меняющими вообще всё, включая до полной несовместимости) распространение БИНАРНЫХ пакетов. Это бред, который вот разве что новичкам и может быть интересен, для более быстро написания "hello world".

N>Ну, тот же vcpkg предоставляет возможность брать именно исходники и всё с единой системой сборки на CMake.

Вот если они для каких-то библиотек переделывают их кривые оригинальные системы сборки на CMake, то за это им большое спасибо. Я до сих пор с ужасом вспоминаю некоторых ОРИГИНАЛОВ. ))) Хорошо что в последнее время наметилась тенденция к переводу всего на CMake. Он хоть и кривой, но хотя бы всем понятный.

А так, не вижу никакого смысла в едином репозитории.

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

Подозреваю что банальный внутренний репозиторий (или вообще файловая шара) с bazel поверх него, будет просто наголову мощнее и удобнее vcpkg.

Здравствуйте, so5team, Вы писали:

_>>Ну вот прямо так и пишешь:
_>>

_>>cc_binary(
_>>    name = "mybinary",
_>>    srcs = ["main.cc"],
_>>    copt = select({
_>>        ":arm": ["-DARM", "-DXAXA"],
_>>        ":x86_my_x_debug": ["-Dx86", "-DXIXI"],
_>>        "//conditions:default": ["-DXREN_KAKAYA_TO"],
_>>    }),
_>>)
_>>

S>Чесно говоря, выглядит убого. Например, я у себя могу проверить, есть ли файлик local-build.rb, если есть по подгрузить его. А в local-build.rb могут быть вещи типа:
S>

S>if 'gcc' == toolset.name && RUNTIME_DEBUG == runtime_mode
S>  global_compiler_option '-fsanitize=address'
S>  global_compiler_option '-fno-omit-frame-pointer'
S>  global_linker_option '-fsanitize=address'
S>end
S>

S>И это все не будет мешаться в описании проекта, поскольку касается только конкретной сборки на конкретной машине.

Ха. Ну во-первых ты вот прямо такое поведение можешь сделать в bazel в одну строчку (это же просто Python со всеми вытекающими из этого возможностями). Но, самое интересное в другом: вообще то bazel и создавался специально для того, чтобы бороться с такими подходами. Потому как они нарушают главное свойство хорошей системы сборки — повторяемость результата. Я уже молчу про возможность распределённой сборки на N машинах и т.п.. ))) Но если всё же есть такое большое желание выстрелить себе в ногу, то никаких проблем и ограничений с этим нет — там просто Pyhton, так что стреляй сколько угодно. )))

_>>В bazel как раз свой язык Starlark (https://github.com/bazelbuild/starlark), который по факту просто встроенный Python с некими минимальными ограничениями.
S>Как-то репозиторий выглядит не сильно живым для языка, который типа должен использоваться активно.

Так это же только сам язык — куда его там дальше менять то? ) Или по твоему в языке CMake что-то там активно развивается? )))

Вот у самой системы сборки https://github.com/bazelbuild/bazel ситуация совсем другая...

S>Я это к тому, что для C++ мира вне Google bazel выглядит маргинально, к сожалению.

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

_>>Лично я не представляю зачем может понадобиться в таком языке как C++ (с его бесчисленными опциями компилятору, меняющими вообще всё, включая до полной несовместимости) распространение БИНАРНЫХ пакетов. Это бред, который вот разве что новичкам и может быть интересен, для более быстро написания "hello world".

S>Многим нравится, что из Conan-а можно забирать готовые Boost-ы, ICU, imagemagick и пр. без необходимости компилировать их у себя на машине.

Угу, собранное под непонятные архитектуры процессора (привет SIMD), с непонятными опциями оптимизации и стандарта языка (ага, стандартная библиотека языка разных версий стандарта "очень хорошо" между собой "дружит"). Не, ну его с такими экспериментами. )))

P.S. Особо забавно было про сборку Boost'а, с учётом того, что многим хватает только тех его библиотек, что собственно не требуют никакой сборки.

Здравствуйте, alex_public, Вы писали:

S>>И это все не будет мешаться в описании проекта, поскольку касается только конкретной сборки на конкретной машине.

_>Ха. Ну во-первых ты вот прямо такое поведение можешь сделать в bazel в одну строчку (это же просто Python со всеми вытекающими из этого возможностями).

И как это будет выглядеть?

_>Но, самое интересное в другом: вообще то bazel и создавался специально для того, чтобы бороться с такими подходами. Потому как они нарушают главное свойство хорошей системы сборки — повторяемость результата.

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

_>Я уже молчу про возможность распределённой сборки на N машинах и т.п..

А это-то тут причем?

S>>Как-то репозиторий выглядит не сильно живым для языка, который типа должен использоваться активно.

_>Так это же только сам язык — куда его там дальше менять то? ) Или по твоему в языке CMake что-то там активно развивается? )))

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

_>Угу, собранное под непонятные архитектуры процессора (привет SIMD), с непонятными опциями оптимизации и стандарта языка (ага, стандартная библиотека языка разных версий стандарта "очень хорошо" между собой "дружит"). Не, ну его с такими экспериментами. )))

_>P.S. Особо забавно было про сборку Boost'а, с учётом того, что многим хватает только тех его библиотек, что собственно не требуют никакой сборки.

Так далеко не все C++ники настолько продвинутые, что понимают все эти штуки. Вот в flame.comp свежая тема про C++ у ученых, она тому подтверждение.

А Conan достаточно умный, чтобы качать бинарные сборки только если характеристики твоей платформы и твоего компилятора совпадают с тем, что лежит на сервере. Кроме того, библиотеки в Conan-е можно и без бинарников распространять, они тогда будут собираться на машине юзера при выполнении conan install.

_>Лично я не представляю зачем может понадобиться в таком языке как C++ (с его бесчисленными опциями компилятору, меняющими вообще всё, включая до полной несовместимости) распространение БИНАРНЫХ пакетов. Это бред, который вот разве что новичкам и может быть интересен, для более быстро написания "hello world".

Архив с исходниками и скриптом сборки тоже называют пакетом. Именно его кладут в репозиторий пакетов. По сути пакет — это то, что лежит в репозитории и то, чем оперирует пакетный менеджер (не важно бинарный он или с исходниками).

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

P.S. Про возможность использования собственного репозитория уже писали. Более того, без этого вообще никак. Упал интернет — ты не можешь взять пакет из центрального репозитория — вся разработка встала. Корпоративщики не захотят выкладывать свой софт в центральный репозиторий (а без них ты не получишь ни бабла ни пользователей своего пакетного менеджера — на энтузиастах далеко не уедешь). Поэтому любой приличный пакетный менеджер умеет работать не только со своим специализированным репозиторием, а с любым git репозиторием. Если ты энтузиаст OpenSource, ты работаешь с центральным репозиторием и GitHub, если это наемная работа — у твоего работодателя свой репозиторий (и в нем будут копии пакетов из центрального репозитория и GitHub).

Здравствуйте, so5team, Вы писали:

_>>Ха. Ну во-первых ты вот прямо такое поведение можешь сделать в bazel в одну строчку (это же просто Python со всеми вытекающими из этого возможностями).
S>И как это будет выглядеть?

load("//:local_config.bzl", local_copt="copt")

cc_binary(
    name = "mybinary",
    srcs = ["main.cc"],
    copt = select({
        ":arm": ["-DARM", "-DXAXA"],
        ":x86_my_x_debug": ["-Dx86", "-DXIXI"],
        "//conditions:default": ["-DXREN_KAKAYA_TO"],
    })+local_copt,
)

Собственно добавил ровно одну строчку по загрузке локального конфига. И далее просто прибавил загруженные локальные настройки (обычный питоновский список строк) к общим настройкам в проекте.

Но это опять же исключительно по твоим пожеланиям. А сам я так никогда не буду делать (ни в одной системе сборки) и никому не советую...

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

_>>Но, самое интересное в другом: вообще то bazel и создавался специально для того, чтобы бороться с такими подходами. Потому как они нарушают главное свойство хорошей системы сборки — повторяемость результата.
S>Так я еще раз повторюсь: это нужно когда следует что-то кастомизировать под частные условия. Вот, скажем, здесь и сейчас у меня какая-то проблема и я хочу воспользоваться санитайзером для упрощения ее поимки. И кастомизирую сборку под себя, причем эта кастомизация вообще не будет затрагивать файлы проектов. Т.е. мне не нужно будет никуда вписывать что-то типа gcc_8_linux_debug_addr_sanitizer.

И в чём проблема поправить файл проекта? ) Добавить ему лишнюю опцию (может тебе этот санитайзер ещё когда-нибудь где-нибудь понадобится)? А вообще крайне странно говорить о пользе "неизменности файлов проектов" в век систем контроля версий...

_>>Я уже молчу про возможность распределённой сборки на N машинах и т.п..
S>А это-то тут причем?

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

S>А Conan достаточно умный, чтобы качать бинарные сборки только если характеристики твоей платформы и твоего компилятора совпадают с тем, что лежит на сервере. Кроме того, библиотеки в Conan-е можно и без бинарников распространять, они тогда будут собираться на машине юзера при выполнении conan install.

Так а опции компилятора то он тоже учитывает или нет? Ну по крайне мере опцию о версии стандарта языка... А то иначе всё равно чушь какая-то будет. И можно ли ему сказать, чтобы всегда тащил только исходники (даже если ему кажется, что в репозитории есть подходящий бинарник) и собирал на моей машине?

Здравствуйте, Reset, Вы писали:

_>>Лично я не представляю зачем может понадобиться в таком языке как C++ (с его бесчисленными опциями компилятору, меняющими вообще всё, включая до полной несовместимости) распространение БИНАРНЫХ пакетов. Это бред, который вот разве что новичкам и может быть интересен, для более быстро написания "hello world".
R>Архив с исходниками и скриптом сборки тоже называют пакетом. Именно его кладут в репозиторий пакетов. По сути пакет — это то, что лежит в репозитории и то, чем оперирует пакетный менеджер (не важно бинарный он или с исходниками).
R>Бинарные пакеты имеют смысл для уменьшения времени сборки. В проекте обычно используется много пакетов и при изменении одного не обязательно пересобирать все остальные чтобы прогнать тесты. Для крупных проектов это очень важно. Понятно, что в ночной сборке ты пересоберешь все с нуля.
R>P.S. Про возможность использования собственного репозитория уже писали. Более того, без этого вообще никак. Упал интернет — ты не можешь взять пакет из центрального репозитория — вся разработка встала. Корпоративщики не захотят выкладывать свой софт в центральный репозиторий (а без них ты не получишь ни бабла ни пользователей своего пакетного менеджера — на энтузиастах далеко не уедешь). Поэтому любой приличный пакетный менеджер умеет работать не только со своим специализированным репозиторием, а с любым git репозиторием. Если ты энтузиаст OpenSource, ты работаешь с центральным репозиторием и GitHub, если это наемная работа — у твоего работодателя свой репозиторий (и в нем будут копии пакетов из центрального репозитория и GitHub).

Хм, ты возможно не совсем понял, что мы обсуждали. Речь шла именно про глобальные репозитории бинарных пакетов (conan, vcpkg и т.п.). Если же говорить о персональных/командных/корпоративных репозиториях, то у меня у самого этого добра полно. Там все нужные мне библиотеки, собранные под все нужные целевые платформы с идеальными для наших целей опциями. И они все естественно собираются отдельно от проектов, перестраиваясь (автоматически) только при обновление исходников этих библиотек или тулчейнов под какую-то целевую платформу.

Здравствуйте, alex_public, Вы писали:

_>Хм, ты возможно не совсем понял, что мы обсуждали. Речь шла именно про глобальные репозитории бинарных пакетов (conan, vcpkg и т.п.).

Как раз нет, это ты неправильно понял. vcpkg в первую очередь исходниками оперирует, а не бинарниками. И, что удобно, предоставляет на все поддерживаемые проекты систему сборки на основе CMake. Он полезен даже тогда, когда ты его не используешь: если какая-то библиотека с полпинка не собирается, то идёшь и смотришь, как её собирают в vcpkg. Он этим и хорош. Ну и бинарники он умеет тоже.
Но и проблем много. Как я и говорил, самая первая — это разные версии. Для этого надо извращаться, своего решения у vcpkg нет, на последней CppRussia докладчик из Nvidia рассказывал, как боролся с этим под Windows. Проблемы есть и другие, поэтому пока нет явного лидера здесь у С++

Здравствуйте, alex_public, Вы писали:

_>

_>load("//:local_config.bzl", local_copt="copt")
_>

А если у меня там еще и параметры линкера задаются, то строка должна будет выглядеть как-то так:

load("//:local_config.bzl", local_copt="copt", local_lopt="lopt")

?

_>И в чём проблема поправить файл проекта? )

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

Соответственно, если нужно вносить подобные правки в каждый проектный файл, то это не есть хорошо.

_>А вообще крайне странно говорить о пользе "неизменности файлов проектов" в век систем контроля версий...

А VCS здесь при чем?

_>Ну а как ты себе представляешь распределённую сборку, если есть шанс, что на двух разных машинах возможен разный результат сборки при одних и тех же внешних настройках?

Представляю это так: build-agent на build-server получает все параметры сборки с мастера, делает чистый checkout исходников для сборки, накатывает туда полученные от мастера параметры и запускает сборку. Соответственно, каким-то другим настройкам особо взяться не от куда будет.

_>Так а опции компилятора то он тоже учитывает или нет? Ну по крайне мере опцию о версии стандарта языка... А то иначе всё равно чушь какая-то будет.

Да, учитывает.

_>И можно ли ему сказать, чтобы всегда тащил только исходники (даже если ему кажется, что в репозитории есть подходящий бинарник) и собирал на моей машине?

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