vcpkg теперь кроссплатформенный

Conan был убог. Эту штуку ждёт та же участь. По крайней мере, пока сборку кода на C/C++ не стандартизируют.

Судя по комментам, vcpkg ещё более убог. Даже фиксированную версию нельзя задать. До cargo как до небес.

Ну вот, очередной apt/dnf/...

В отличии от перечисленных, он работает не только на отдельных Linux-овых дистрибутивах.

Впрочем, на этом все хорошее в vcpkg, имхо, заканчивается.

Даже не рядом.

Явшоке, микрософт пишет «we are committed to bringing you the most productive development tools and services to build your apps across all platforms» - куда мир катился и докатился?

Даже фиксированную версию нельзя задать.

А можно цитату на ээтот счет? По-моему, они мимкрируют под dpkg, там фиксированную версию задать можно.

Похоже что нет - все «пакеты» у них в https://github.com/Microsoft/vcpkg/tree/master/ports, и там нет версионности.

Ну там-то да, я тоже не нашел... и в исходниках разрешения зависимостей вроде нет. Но тогда это какая-то совсем уж убогая поделка.

P.S. они походу даже разбиение длинных строк зависимостей не осилили. Ынтерпрайз епт.

Лолшто? Нет версионности?

Нет версионности зависимостей.

Зачем пробовать этот крап, когда всё есть в нативном репозитории, свежее, совместимое и установленное по предсказуемым путям? Пусть вместе с conan'ом, buckaroo, biicode (и что там ещё наублюдили и ещё не сдохло) отправляется на винфак, где конечно в отсутствие пакетного менеджера без этих костылей не обойтись.

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

Такое, вроде, только Nix и подобные могут.

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

У dpkg есть опция --root=DIRECTORY у RPM (ЕМНИП) тоже. Отседова и плясать. Правда придется обмазаться обертками (помимо apt/dnf/...).

Ты сам-то пробовал вот этим пользоваться?

https://github.com/Microsoft/vcpkg/issues/1681#issuecomment-324160402

Microsoft, позорный и тупой, как всегда.

По крайней мере, пока сборку кода на C/C++ не стандартизируют.

Че там еще стандартизовывать, все и так одинаково плохо.

До cargo как до небес.

а, этот очередной npm-подобный (что само по себе оскорбление) кусок оверинжинеринга с lock-файлами, чтобы хранить недетерминированное решение NP-полной задачи там, где она вообще не должна ставиться.

Слава богам, хотя бы в Go начали понимать, насколько это убого.

майкрософт врёт

Вот так открытие.

Кстати, а MinGW с его кучей пакетов - это ли не то, с чем пытается конкурировать этот vcpkg? Я под оффтоп часто юзаю именно MinGW когда надо тучу опенсорсных либ прилепить, которых я нацеплял под линь. На 99% всегда всё есть в репах мингвшных.

Я очень давно не имею дело с вендой, но на LOR говорят, что в MinGW используется порт pacman (ага, того самого, из Arch).

Нет, vcpkg собирает пакеты из исходников. Даже жалкое подобие use-флагов есть.

Да лааадно. Несколько разных вариантов Make, самописные скрипты для сборки, meson, qmake, cmake, анал карнавал, вот это всё вместо одного стандартного простого в использовании инструмента. Сравни это с cargo у rust или cabal у haskell.

Хотя даже этот зоопарк не является самым большим препятствием для появления пакетного менеджера для C/C++. Самая большая проблема — толпа программистов на этих языках, у которых при попытке осилить что-то, что появилось после окаменения мамонтовых фекалий, начинает по швам трещать черепная коробка. На этом форуме есть несколько отличных примеров подобных личностей.

Несколько разных вариантов Make, самописные скрипты для сборки, meson, qmake, cmake, анал карнавал, вот это всё

и есть стандартизованная сборка кода на C/C++. Молись, чтобы не стандартизовали еще столько же бессвязного лепета.

Сравни это ... cabal у haskell.

Это который в свое время в одиночку популяризовал nix, потому что проще собрать маленькую ОС, чем удовлетворить зависимости через cabal?

Задница со сборкой везде, от Python до Clojure. В С/C++ это задница бабуина в цыганском наряде, ожидаемо яркая, пестрая, непредсказуемая и разномастная.

пакетного менеджера для C/C++

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

и есть стандартизованная сборка кода на C/C++. Молись, чтобы не стандартизовали еще столько же бессвязного лепета.

Я этот комикс уже по URL узнаю. Тем не менее, хотелось бы иметь один инструмент. И поддержку модулей в самом языке, пожалуйста.

Это который в свое время в одиночку популяризовал nix, потому что проще собрать маленькую ОС, чем удовлетворить зависимости через cabal?

Nix стал популярен, потому что через него можно подтягивать и сторонние библиотеки. А проблему с зависимостями в итоге решили через Stack.

Задница со сборкой везде, от Python до Clojure. В С/C++ это задница бабуина в цыганском наряде, ожидаемо яркая, пестрая, непредсказуемая и разномастная.

Задницы разные бывают, чувак. В C/C++ — просто лютый треш, из-за которого билд-инженер — это отдельная должность.

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

Если мы хотим фишки типа песочниц с локальными библиотеками, то уже нет.

Это вы про фанбоя autotools?

Нет, ибо базовых возможностей хватало.

А вообще, если правильно запакетить, то можно нормально устанавливать несколько версий зависимостей параллельно.

Я не про кого-то одного. Здесь и не только здесь подобных личностей хватает.

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

Если мы хотим фишки типа песочниц с локальными библиотеками, то уже нет.

То всё еще да.

Если мы хотим фишки типа песочниц с локальными библиотека ми, то

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

Ну понятно, просто суть то одна - прилепить сторонние либы к приложению? Верно? Взять тот же MinGW из поставки Qt - там есть только сам кутэ и компилятор gcc. Что-то стороннее прилепить проблематично. И vcpkg и mingw решают эту задачу, я правильно понимаю? А то что одно собирает из исходников, а другое нет - это для моего вопроса дело второе.

Только vcpkg собирает даже gtk для MSVS, а MinGW с MSVS не работает.

Ну я понял, но по сути это инструменты одного целевого назначения? Просто чтоб я понимал.

А чем оно лучше pkgsrc?

На Linux использовать conan для подъёма билдсервера на Travis было крайне удобно. Локально на своей машине, пожалуй, проще собрать библиотеки через checkinstall.

На Windows этот vcpkg незаменим для преподавания: гораздо легче объяснить слушателям курсов, как собрать vcpkg из бутстрапера и потом просто скачать несколько пакетов под нужный триплет, чем долго полоскать им мозги про include paths, library paths, linker inputs и так далее.

Хорошая новость - один инструмент на всех платформах всё-таки удобен. На Windows vcpkg выигрывает у conan. На Linux/MacOSX conan дефолт, vcpkg на запасе.

В C/C++ — просто лютый треш, из-за которого билд-инженер — это отдельная должность.

У нас нет такой должности, у соседней Java-конторы, однако, есть. В чём суть билд-инженера?

https://www.quora.com/What-is-the-work-of-a-software-build-or-release-enginee...

Особенно пункты 1 и 5 в первом ответе.

На первый взгляд это скорее куцый аналог homebrew