В любое. С cmake тот же clion ещё хоть как-то прожует (но тоже криво), а автотулз нормально ни vscode, ни clion, ни эклипс какой-нибудь нормально не импортирует.

Я понимаю что чоткие посоны пишут в виме/емаксе, но блин дебаг в виме это треш и угар если проект чуть сложнее хелловорлда

С пистоном тоже не могут. Потому, что пистон - говно. Meson - говно. Все популярные системы сборки - говно.

shell-скрипты в онтопике и батники в винде

shell-скрипты есть и на винде

писать внешние скрипты для кодогенерации

более того, они, скорее всего, вообще подразумевают питон

qtcreator понимает cmake

pkg-config не работает с нативной экосистемой Windows

Там нет никакой экосистемы. Разработчики прописывают пути руками до библиотек либо включают их в состав своего проекта.

Неудобство разработки на C/C++ по мне – один из основных недостатков Windows.

Там нет никакой экосистемы. Разработчики прописывают пути руками до библиотек либо включают их в состав своего проекта.

Зачем это делать?

А как ещё? Как система сборки найдёт сторонние библиотеки?

А как ещё? Как система сборки найдёт сторонние библиотеки?

С помощью vcpkg/conan

cmake -CMAKE_TOOLCHAIN_FILE=<vcpkg-root>/scripts/buildsystems/vcpkg.cmake .. -G Ninja

Вот посмотри как выглядит хорошая кросплатформенная заготовка проекта:

https://github.com/cpp-best-practices/cpp_starter_project

А вообще в Windows много встроенных либ, какие-то проекты можно делать и без зависимостей вовсе…

-CMAKE_TOOLCHAIN_FILE=/scripts/buildsystems/vcpkg.cmake

Ну то есть какие-то пути прописывать руками в каждом проекте таки надо. В UNIX-like системах работает просто cmake .. без каких либо путей и всё само находится.

Ну то есть какие-то пути прописывать руками в каждом проекте таки надо.

Если открывать из Visual Studio и предварительно сделать:

vcpkg.exe integrate install

То Visual Studio будет сама подставлять путь до vcpkg и не нужно будет вообще никаких путей указывать :)

Но если самому в консоли запускать cmake, то нужно указать в CMAKE_TOOLCHAIN_FILE путь до vcpkg.cmake

сообщество C/C++-разработчиков могло бы организовать какой-нибудь централизованный репозиторий, в который бы выкладывали FindModules к популярным библиотекам.

Зачем когда есть pkgconfig который есть на всех UNIX-like системах? Давно пора уже выпилить все эти модули. Пользователи Windows и компилятора Microsoft пусть страдают с ручным прописыванием путей, модули для этого не требуются.

Все эти модули – это исключительно вендопроблемы.

взять её исходники с гитхаба, всунуть в ide

Консоль – лучшая IDE. Говорю это как фанат GUI.

но блин дебаг в виме это треш и угар

Отлаживать от слова «лажа» (с) суровые оберонщики. Отладочного вывода и вывода стека достаточно в 95% случаев.

Если открывать из Visual Studio

Это за которую надо платить кучу денег и которая весит кучу гигабайт? Не нужно.

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

Пять лет назад, когда делал для развлечения самописное ядро. Ну, там отладчиком прямо к qemu подрубаться пришлось.

А до этого – вообще в ВУЗе.

Видимо, я делаю что-то не так, ага.

meant to be extremely fast
every moment a developer spends writing or debugging build definitions is a second wasted
as user friendly as possible

Тут вау-эффект.

.py

А вот тут больно было.

Это за которую надо платить кучу денег и которая весит кучу гигабайт? Не нужно.

Есть бесплатная версия, которую можно использовать только при определенных условиях.

Но вот сколько стоит полная версия: (8 ноября выходит visual studio 2022, не стоит покупать сейчас visual studio 2019):

https://www.microsoft.com/en-us/d/visual-studio-professional-2019/dg7gmgf0f6q1?activetab=pivot:overviewtab

(пожизненная лицензия на приложение, не подписка которую нужно продлять, я не люблю подписки…)

А вот сколько занимает куча гигабайт(у меня там установлен ещё и clang, и arm64 компилятор и прочее, в минимальной выборе компонентов для С++, там вдвое меньше будет занимаемое место): https://imgur.com/a/7jMO7Bm

Да, всё так.

Зачем когда есть pkgconfig который есть на всех UNIX-like системах? Давно пора уже выпилить все эти модули.

Ну вот так вот CMake и был спроектирован, что использовать модули в нём удобнее чем использовать pkgconfig. Все современные библиотеки тянут с собой эти модули, тот же Qt или SDL2. В довесок к уже существующим pc-файлам для pkgconfig. Так вот нарушение обещания CMake-разработчиков засорило бесконечное количество репозиториев этим хламом и сподвигло мейнтейнеров на кучу дополнительной работы.

Там нет никакой экосистемы. Разработчики прописывают пути руками до библиотек либо включают их в состав своего проекта.

Раньше не было. Сейчас появились всякие vcpkg и прочие conan’ы.

Как оно работает? Там что-то вроде pkgconfig?

Как оно работает? Там что-то вроде pkgconfig?

Сильно не вникал, но похоже что через этот тулчейн-файл CMake и эти Find-модули, как было сказано выше. В любом случае раньше было именно как ты описал, а сейчас разработчики прямо как в UNIX-like могут написать в консольке что-то типа vcpkg install gtk3 sqlite и дальше добавлять в CMakeLists.txt нужные им библиотеки и утилиты через find_package(). А студия сделает многое автоматом.

Ну то есть какие-то пути прописывать руками в каждом проекте таки надо. В UNIX-like системах работает просто cmake .. без каких либо путей и всё само находится.

Это уже специфика в силу Windows-наследия. Кросскомпиляция под UNIX-like тоже cmake .. не ограничится. Суть-то именно в том, что раньше там подобного способа официально не было (был MSYS2 зато), а теперь следуя гайдам от Microsoft можно превратить свой Windows в аналог Arch Linux или даже Gentoo.

Консоль – лучшая IDE. Говорю это как фанат GUI.

Странно, ты вроде говорил что нечего использовать консоль не по назначению. А тут прямо строки из «Unix as IDE» пошли.

Неудобство разработки на C/C++ по мне – один из основных недостатков Windows.

Не только неудобство разработки на C/C++, но и вообще разработки. В Microsoft сидят далеко не дураки и они быстро почувствовали как теряют «Developers, Developers, Developers», как побеждает не Windows-style ведения разработки, а UNIX-style. Именно поэтому не только сам Windows перешёл на Git, а в Microsoft Visual Studio появилась шикарнейшая поддержка Git, но и они всякие шутки вроде GVFS (переименовали из-за конфликта имён с GNOME’овской технологией в VFSForGit) запилили https://github.com/microsoft/VFSForGit

Это ещё не говоря про покупку GitHub, внедрения WSL, WSL2 и переработку святая всех святых cmd.exe и notepad.exe (добавили туда Unix line endings)!

А всё потому что вот это вот: https://insights.stackoverflow.com/survey/2020#technology-platforms

Шутка ли, Linux стал у разработчиков и IT-специалиство популярнее чем Windows.

Странно, ты вроде говорил что нечего использовать консоль не по назначению.

Писать команды вроде cmake .. -G Ninja, ninja install и т.п. это как раз по назначению. Я в первую очередь против пседвографики и интерактивности в консоли. Haiku ещё умеет чтобы по клику ошибки компиляции в консоли открывался редактор кода по умолчанию на месте ошибки.

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

Видимо, я делаю что-то не так, ага.

А я часто использую отладчик (точнее frontend к GDB в лице Qt Creator). Удобно для изучения чужого кода, запутанных алгоритмов, при реверс-инжиниринге и просто пошагать по строчкам глядя как именно изменяется набор переменных/кусок памяти.

Отлаживать от слова «лажа» (с) суровые оберонщики. Отладочного вывода и вывода стека достаточно в 95% случаев.

Backtrace-выхлоп это когда программа работает неправильно и падает, а вот когда программа работает неправильно и не падает, тут удобство отладчика и раскрывается в полной мере по сравнению с теми же отладочными fprintf’ами, которыми, кстати, я тоже с удовольствием иногда пользуюсь.

Вывод стека это когда программа работает неправильно и падает

Не только. В моей программе SystemManager можно смотреть стек любого потока в любое время не прерывая исполнение программы. Напишите в коде fgetc(stdin); и будет вам breakpoint. Я ещё хотел сделать чтобы по двойному клику строчки в стеке открывался редактор кода на месте вызова.

Получается UNIX way: вместо одного комбайна IDE несколько небольших утилит каждая из которых выполняет свою функцию.

Как оно работает? Там что-то вроде pkgconfig?

При установке библиотек есть папка «vcpkg\installed\x64-windows\share»

Там для установленных библиотек либо создаётся папка с файлом заглушкой, если для библиотеки есть встроенная поддержка в cmake.

Например:

The package zlib is compatible with built-in CMake targets:

    find_package(ZLIB REQUIRED)
    target_link_libraries(main PRIVATE ZLIB::ZLIB)

Или в папку кладутся .cmake файлы от разработчиков библиотеки:

Например, в папке grpc есть файлы

gRPCConfig.cmake
gRPCTargets.cmake
gRPCTargets-debug.cmake
gRPCTargets-release.cmake

Видимо они как-то создаются из этих in файлов: https://github.com/grpc/grpc/blob/master/cmake/gRPCConfig.cmake.in

Или если разработчик не предоставляет .cmake файлов, то создаётся папка unofficial-somename, и туда кладутся такие же cmake файлы, только от разработчиков vcpkg.

Например есть unofficial-sqlite3.

Всего это знать не нужно.

нужно лишь прочитать вывод после установки библиотеки. Там напишут что нужно писать, чтобы подключить библиотеку в Cmake.

Например:

The package sqlite3:x64-windows provides CMake targets:

    find_package(unofficial-sqlite3 CONFIG REQUIRED)
    target_link_libraries(main PRIVATE unofficial::sqlite3::sqlite3)

https://imgur.com/a/5GGPwW0

Configure complete, now type ‘make’ and pray.

Вся суть Autotools.

    find_package(unofficial-sqlite3 CONFIG REQUIRED)
    target_link_libraries(main PRIVATE unofficial::sqlite3::sqlite3)

ГЛАЗА!

И ещё один.

polkit 0.120

WARNING WARNING WARNING: This is a prerelease on the road to polkit
1.0. Public API might change and certain parts of the code still needs
some security review. Use at your own risk.

NOTICE:
This is the LAST version to support AUTOTOOLS build system, as it has been obsoleted
by meson build system.
The next release of polkit will REQUIRE meson build system.

https://gitlab.freedesktop.org/polkit/polkit/-/blob/92b910ce2273daf6a76038f6bd764fa6958d4e8e/NEWS

Принтами чтоль дебажишь? Не, спасибо, чёт не хочу обратно на перл

Видимо, я делаю что-то не так, ага.

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

Что не так? По сравнению с любыми крестами (да и с растом) это прям эталон красоты

Ого.

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

А чем в целях интеграции произвольного пропета с произвольной IDE плох compilation database?

Импорт Autotools в CLion работает.

Если что-то конкретное не работает — пишите в багтрекер.

Попробую либу в clion запихать в понедельник, авось съест, посмотрим. С вскодом не взлетело. Раньше юзал clion для написания бэка к llvm, за исключением тормозов норм, но снова лицуху брать ради дебага одного теста лениво, видимо триал возьму

В целом имхо внешне (не внутри, внутри там пипос) idea-based наиболее адекватные ide.

ГЛАЗА!

Напомнило.

Принтами чтоль дебажишь?

Да. Это куда более мощный инструмент позволяющий выводить необходимую информацию. Ещё он без проблем работает в релизной сборке, не требуя переключать проект на тормозную отладочную сборку.

Да это эталон красоты по сравнению с лютым нечитабельным ужасом Autotools и всяких M4.

Это куда более мощный инструмент позволяющий выводить необходимую информацию.

Только обязательно следует помнить что stdout буферизируется. У меня давно выработалась привычка использовать именно stderr для отладки printf’ами.

Рекомендую последний 2021.3 EAP — там Autotools-проекты по умолчанию собираются out-of-tree (тот самый VPATH).

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

В современном мире достаточно делать pkg_check_modules, если FindModules вдруг не работает из коробки.

Мы тут про системы сборки говорим, а не про дистрибутивные репозитории. pkgconfig, так же как и cmake может искать пакеты где ему скажут, а не только в /usr/share/pkgconfig. И когда твой софт зависит от 3rdParty библиотек которые нужно подключать в разных конфигурациях (например profile и release) в зависимости от, pkgconfig сливает.

Наброшу: чем meson лучше scons? Оба на python.

чем meson лучше scons?

В разы быстрее сборка. Иногда на порядки.

И когда твой софт зависит от 3rdParty библиотек которые нужно подключать в разных конфигурациях

Виндопроблемы. В Линуксе это не нужно. Если что, можете собрать из исходкиков как вам надо.

В разы быстрее сборка

Так meson сам не собирает, он использует ninja. В scons правда поддержка ninja пока экспериментальная есть.

Так meson сам не собирает, он использует ninja. В scons правда поддержка ninja пока экспериментальная есть.

Напиши авторам meson, что их данные устарели, если ты думаешь что scons не в разы медленнее чем meson.

Вот что они пишут, почему meson, а не Scons

Scons:

Slow. Requires you to pass your configuration settings on every invocation. That is, if you do scons OPT1 OPT2 and then just scons, it will reconfigure everything without settings OPT1 and OPT2. Every other build system remembers build options from the previous invocation.

И вот какие результаты приводят:

https://raw.githubusercontent.com/wiki/jpakkane/meson/emptytime.png

https://raw.githubusercontent.com/wiki/jpakkane/meson/buildtime.png

Что там на шкале? Дни, годы?

will reconfigure everything

Так это фича вдобавок к изоляции окружения сборки. Правда с этой изоляцией иногда бороться приходится.