CMake 3.28

autotools / cmake / meson это всё одинаково ненужная блоатварь. Но почему-то в головах сборщиков укоренилась мысль что что-то из этой помойки на выбор обязательно надо всунуть в проект.

Господин-нонкомформист чем собирает?

Если ты не знал, то автотулзы ничего не собирают. Это побочная ненужная нашлёпка на make.

Собственно, для сборки проектов из большого количества исходных файлов давным давно придумали make, а если файлов мало и они не используют некроссплатформенную экзотику и прочие сложности - в большинстве случаев достаточно одной шелл команды типа gcc -o binname *.c $CFLAGS $LDFLAGS.

для сборки проектов из большого количества исходных файлов давным давно придумали make

Господи, да почему же сишники такие луддиты? Ты что-нибудь сложнее хелловорлдов когда-нибудь писал? Ну чтобы несколько сотен файлов и с поддержкой инкрементальной сборки. Боюсь представить размер makefile портянки и её сложность поддержки. За попытку собирать проект самописным makefile нужно увольнять.

Ну чтобы несколько сотен файлов и с поддержкой инкрементальной сборки. Боюсь представить размер makefile портянки и её сложность поддержки

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

Инкрементальная сборка там автоматом получается.

Не получается. Чтобы была инкрементальная сборка нужно парсить директивы include, чтобы узнать от чего файл зависит. Иначе тебе придётся вручную этот граф прописывать в мейкфайлах и это помимо обычных зависимостей между объектными файлами. А без этого можешь попасть в wtf ситуацию когда у тебя часть объектников не пересоберётся и программа будет не консистентной.

Это, кстати, действительно так. Хотя я и согласен с позицией firkax, я бы не сказал что писать портянки на Makefile чем-то лучше.

К сожалению, в этом мире существуют и другие компиляторы кроме GCC и Clang. Я на днях ускорил сборку включив (уже готовый, правда) модуль использующий компилятор для вычисления зависимостей вместо использования встроенного, который написан на Python и соответствующе питону тормозит.

Несмотря на то, что это прекрасно работает с GCC и Clang, потому что там есть специальный флаг генерирующий зависимости в синтаксисе Makefile, аналогичного флага у MSVC не существует. Самое близкое это /showIncludes, который невозможно распарсить, если системным языком стоит что-то отличное от английского языка. Собственный готовый модуль реализующий это для MSVC не учитывает ничего кроме английского.

Я проверил что делает любимая симейком и мезоном ниндзя и… у них тоже нет решения. Максимум, что можно сделать – заранее передать альтернативную строчку, что возможно и делает CMake и Meson при генерации ниндзяфайла.

/showIncludes, который невозможно распарсить, если системным языком стоит что-то отличное от английского языка

Как же не хватает банального LANG=C, да? С виндой вообще много сложностей. Кстати /sourceDependencies не подойдёт?

Вижу тут его советовали:

https://github.com/ninja-build/ninja/issues/1766

Но там у вас поди ещё VC++6 не отпускает? D:

Уже давно отпустил, можно запиливать. Потом в апстрим заслать :)

MSVC

Зачем его использовать для сборки кроссплатформенного софта?

Потому что кроссплатформа это множество, в которое помимо онтопика входит и оффтопик.

Для оффтопика есть MSYS.

Msys штука специфическая. Некоторые либы можно под него не собрать.

Можно пример либы, которая собирается под линуксом, не собирается под MSYS, но при этом собирается под MSVC?

Ну вот PyTorch например

https://github.com/pytorch/pytorch/issues/24460#issuecomment-1383277152

https://stackoverflow.com/questions/76153651/why-is-pytorch-failing-to-build-with-mingw

Тут просто логика такая: все таки родное для винды это msvc. И при разработке некой либы, например я бы так рассуждал, разработчику может прийти мысль: блин да кто под виндой юзает этот ваш msys, наверное потенциальным пользователям (другим программистам) потребуется в первую очепедь версия для msvc.

Можно пример либы, которая собирается под линуксом, не собирается под MSYS, но при этом собирается под MSVC?

QtWebEngine еще например. Она использует хромиум, который на оффтопике официально поддерживает только MSVC и шланг (через обертку clang-cl).

Ну, то есть, все проблемы из-за того, что кто-то ССЗБ и запилил что-то, завязав это на MSVC

MinGW, если ты не в курсе, не соблюдает их C++ ABI. Да и Си не всегда совместим. :)

Ну чтобы несколько сотен файлов и с поддержкой инкрементальной сборки

Вот у меня щас такой. Мейкфайле в пару сотен строк, куда ещё проще. Чего сложного это поддерживать?

Это не луддизм. Ложку изобрели тысячу лет назад, но она прекрасно справляется, вы же каждый день изобретайте что-то новое, хотя по сути ничего нового и она ложкой так и остаётся, сами учитесь ей пользоваться каждый день, а всех кто продолжает пользоваться ложкой обзываете луддитами.

Мы не против нового, тока на хрена новую ложку изобретать?

Если тебе сложно поддерживать мейк на пару сотен файлов, а мне нет, может ты просто делаешь что-то не так?

Ты тоже сидишь без инкрементальной сборки? У меня проект с нуля собирается 20 минут. Хочешь тратить столько времени после любого даже самого малого изменения в коде?

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

Ты тоже сидишь без инкрементальной сборки?

Ты точно мейком пользоваться умеешь?

Ты точно мейком пользоваться умеешь?

Нет конечно. Зачем мне эта страхолюдина.

Однако я дежурно напоминаю, что чтобы правильно инкрементально собирать например c/c++ нужно парсить файлы и извлекать оттуда список инклюдов и добавлять их в зависимости. Make этого не умеет. Хакиры конечно, придумали костыль в виде ключиков для gcc, но это не make, о котором мы здесь говорим, это сторонняя пришлёпка.

Мейкфайле в пару сотен строк, куда ещё проще.

Пока туда стороннему человеку не пришлось заглянуть. Потому что стандартов никаких нет и каждый пишет как хочет. У меня был негативной опыт линковки с одной библиотекой. Там автор тоже был хакиром и сделал сборку на самописном makefile.

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

Ты точно мейком пользоваться умеешь?

Нет конечно. Зачем мне эта страхолюдина.

Однако, критикуешь.

Потому что стандартов никаких нет и каждый пишет как хочет

Ночь программирования вообще темна и полна ужасов

У меня был негативной опыт

Так про что угодно можно сказать и это почти всегда правда)

автор об этой возможности нормально не позаботился

Всякое бывает

автор тоже был хакиром и сделал сборку на самописном makefile.

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

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

Ваше решение поставленной задачи?

А почему это вообще система сборки должна думать об IDE? Почему не наоборот? Шлангу для дополнялок хватает compile_flags.json, добавь сюда дерего исходников - любой IDE должно быть достаточно для старта.

А так хвост виляет собакой, всякие IDE и виндоуз, которые клали болт на POSIX. Make, shell, окружение - всё это стандартизировано, вопросы надо задавать тем, кто им не следует. А CMake - куча кривых костылей. Винда должна вкрутить в себя POSIX shell, make, pkgconfig, и прочие утилиты, CMake все дружно вынесут на мороз. До этого ни один приличный разработчик не должен ничего писать под это недоразумение с особым путём.

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

добавь сюда дерего исходников

ну вот и добавь - в мейкфалах этого нет

а ещё нет в мейкфалах списка используемых библиотек

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

За забором, как следует из названия, должно много странного находиться. А там дрова лежат

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

Ну так надо тыкнуть в своей ide на корень исходников, дать ей фалги компиляции (в compile_flags.json), которые содержат и инклуд пути, и используемые библиотеки, дефайны, и вообще всё необходимое.

Если твоя IDE не может стартануть имея эту инфу, то она на букву Г должна называться.

Винда ведь не просто так идёт «своим путём», плевать им на удобство, портирование, переносимость. Им нужна своя паства. Значит винда соблюдать стандарты не хочет, а вот кресты должны вкрутить в себя систему сборки, чтобы везде собиралось. А может им на йух надо сходить?

которые содержат и инклуд пути, и используемые библиотеки, дефайны, и вообще всё необходимое

по сути, CMake этим и занимается. Прописывать всё это вручную в проекте чуть сложнее калькулятора - это песец

Ну в целом да, только вот вместо простого

$ pkgconf --libs --cflags sdl2
-I/usr/include/SDL2 -D_REENTRANT -lSDL2

cmake предлагает проштудировать и юзать эту портянку. И так во всём. А генерация IDE’шного мусора это вишенка, кричащая о всей ущербности этого поделия.

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

Помнится генерил модуль для либы
Если это ок, то лучше я выйду:

if(opt_install)
  include(CMakePackageConfigHelpers)
  write_basic_package_version_file(${PROJECT_NAME}ConfigVersion.cmake
    COMPATIBILITY AnyNewerVersion
    ARCH_INDEPENDENT)
  install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
    DESTINATION lib/cmake/${PROJECT_NAME})

  install(TARGETS tabl curtabl stream_pipe EXPORT
    ${PROJECT_NAME}Config)
  install(EXPORT ${PROJECT_NAME}Config
    NAMESPACE ${PROJECT_NAME}::
    DESTINATION lib/cmake/${PROJECT_NAME})
  # Adds *Config.cmake to the build dir.
  export(EXPORT ${PROJECT_NAME}Config
    NAMESPACE ${PROJECT_NAME}::)

  install(DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/include/
    DESTINATION include/${PROJECT_NAME})
endif()

PS: тут, чуть больше чем cmake модуль, но дух CMake’а отражает, это безумие.

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

Не осилил? Бывает…

Нет, просто надоело жрать дерьмо.

Реакция «зелен виноград» выступает способом самозащиты от фрустрации путём обесценивания цели.

А что за цель? Выработать толерантость к CMake’у? Ну да, сорян, подвёл команду, не могу более сдерживать рвотные позывы.

Ну да, сорян, подвёл команду, не могу более сдерживать рвотные позывы.

Я тебя понимаю, у меня такое же к VS/Xcode. Двадцать раз кликни для элементарной фигни.

Шутка

Эээээээээээ, эти борщ едят палочками.

cmake предлагает проштудировать и юзать эту портянку.

Во-первых да. Надо читать документацию к такому мощному инструменту, если хочешь его использовать на профессиональном уровне. RTFM никто не отменял.

Во-вторых преимущество симейка сегодня как раз в том, что из-за распространённости на все распространённые проблемы уже есть готовые рецепты. (Оговорюсь тут, что иногда легаси-ответы всплывают первыми, но они тоже работают!). Это не значит что не надо читать документацию. Документацию нужно тоже почитать, это полезно.

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

У симейка конечно есть серьёзные проблемы, но только не в поиске и подключении библиотек, где он лучший.

И да, у него есть прекрасная обёртка для pkg-config, если всё остальное не работает.

а ты предпочитаешь поливать помоями известный продукт, которые ты даже не попытался изучить.

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

А главное - это его родовые травмы, он костылём был, костылём живёт, костылём и помрёт генеря мусор для вазелиновых студий. Цели у проекта должны быть годными. Компиль напрямую вызывать, а не встравиваться костылём; Не искать либы на всяких дырявых осях типа венды во всех щелях и устанавливать тоже черт пойми куда, а признавать только UNIX like организацию диска, создавать в винде соответствующее дерево директорий в корне и кидать всё туда. Плюс какой-то демон для венды, который будет следить за установкой необходимыми переменными окружения (HOME, например).

Вот если бы так дела обстояли, то другой бы разговор был. При некоторой критической массе проектов, которые юзают такой правильнй cmake, венде бы пришлось признать реальность и сделать себя UNIX like. А так - ущербная поделка-костыль, да ещё и с ужасным DSL, лучше уж мезоном. Если по сути разницы нету, то зачем блевать от cmake’а?

Эталонный бред.

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

Вперед, я на это посмотрю.

сделай так чтобы это работало под виндой

А это кстати очень просто делается.

1. Выкидывается штудия вместе с тем хламом на 10 GB который нужно поставить ради того чтобы скомпилить main() {return 0;}

2. Ставится MSYS2: https://www.msys2.org/ в котором есть pkgconfig и прочие удобнейшие UNIX-тулзы.

это все работает (и то не факт, сильно подозреваю что у всех этих MSYS2 есть куча своих wtf-ов) до первого коммерческого контракта с партнерами, у которых MSVC

Ставится MSYS2

Что в конце 2023 года интереснее, MSYS2 или Cygwin?

Что в конце 2023 года интереснее, MSYS2 или Cygwin?

У них так-то разные цели. MSYS2 не реализует POSIX полноценно, тогда как Cygwin старается это сделать, поэтому всякий сложный софт активно юзающий POSIX, к примеру… х.з., Kannel какой-нибудь, соберётся под Cygwin но не соберётся под MSYS2.

А так MSYS2 конечно в 2023 году рулит и педалит.

Он предлагает практически полный набор библиотек и средств разработки, к которым привыкли разработчики в Linux дистрибутивах.

Более того, там есть такие штуки как qt5-static и qt6-static

• https://packages.msys2.org/package/mingw-w64-x86_64-qt5-static
• https://packages.msys2.org/package/mingw-w64-x86_64-qt6-static

То есть ты можешь собрать статическую версию программы на Qt используя простейшие команды по типу:

pacman -S mingw-w64-x86_64-gcc mingw-w64-x86_64-g++ mingw-w64-x86_64-qt6-static make
qmake CONFIG+=release project.pro
make

И получить stand-alone исп. файл так любимый пользователями Windows.

А ещё там довольно быстрый пакетный менеджер из Arch Linux – pacman. В общем хорошая вещь, многие проекты под Windows собираются в этом окружении, к примеру, KeePassXC.

Я последний раз MSYS (старый, 1.0.11) тыкал несколько лет назад, когда экспериментировал с сетевыми модулями Qt. Саму Qt в статике и проект под неё я собрал «обычным» MinGW, но когда мне потребовался OpenSSL, взял MSYS.

С новым MSYS2 ничего собирать не нужно, там уже идёт пакетный менеджер и скомпилированные пакеты. То есть ставишь какой-нибудь Qt, SDL, SDL2 и просто собираешь код.

Но для Qt наверное лучше всё-таки использовать windeployqt вместо статической сборки.

Но для Qt наверное лучше всё-таки использовать windeployqt вместо статической сборки.

Смотря куда. Если делать дистрибутив с 10 экзешниками и 30 DLLями — да.

Но вот тот же DoubleContact у меня — это один жирный бинарь (есть ещё консольный contconv на той же кодовой базе, но его ЦА, думаю, не более 1-2% от общей ЦА пользователей основного проекта). Если даже у пользователя на машине будут стоять кутешные проекты — это будут проекты других авторов, тянущие другие версии Qt. И его собрать статикой значительно выгоднее, даже тупо по объёму дискового пространства. И подозреваю, что у большинства виндового опенсорса, кроме действительно крупных проектов, ситуация примерно такая же.

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

В 2015 году даже делал статические сборки на Qt 4 потому что они весили меньше в два раза, условно 8 МБ против 15 МБ для приложения-кнопки без особой логики.

За статическую сборку нужно денег занести.

Только для проприетарщиков. А также, если я правильно понимаю суть LGPL, то достаточно поставлять в комплекте объектные или исходные файлы Qt, чтобы не нарушать лицензию.

А также, если я правильно понимаю суть LGPL, то достаточно поставлять в комплекте объектные или исходные файлы Qt, чтобы не нарушать лицензию.

нет конечно. Нужно свои объектные(а также тулчейн) или исходные файлы давать. Чтобы другой пользователь мог слинковать программу со своей версией Qt.

Если собирается под какую-то встраиваемую систему, с проприетарным компилятором, то LGPL фактически вынуждает покупать Qt(потому что ты не можешь предоставить toolchain, а по лицензии ты обязан это сделать)

Для десктопа LGPL норм, если использовать so/dll и собирать свободными компиляторами.

Отчасти поэтому на Android Qt и не взлетел. Лицензия конченная.

Вот одна из статей где подробнее рассматривается лицензия: https://embeddeduse.com/2016/04/10/using-qt-5-6-and-later-under-lgpl/

You must provide a cross-compiling toolchain together with the necessary libraries, headers, files and tools such that users can build the modified Qt version for the target device. A pretty simple way to satisfy this obligation would be to install the toolchain in a virtual machine and make this virtual machine available to the users.

Для OSS проектов?

OSS

Знал бы я, что значит :-)

Open-source software (OSS) is computer software that is released under a license in which the copyright holder grants users the rights to use, study, change, and distribute the software and its source code to anyone and for any purpose.[1][2]

https://en.wikipedia.org/wiki/Open-source_software

Хм, да вроде бы очень распространённая аббревиатура, чтобы уточнять.

А я загуглил https://en.wikipedia.org/wiki/Operations_support_system

Для OSS проектов?

Open-source software

Я думал да. Хотя могу ошибаться.

Open Sound System

Очередной слышавший звон, но абсолютно не понявший его сути. Я уже перестал удивляться.

В контексте моего комментария вообще получается, что я за статическую сборку GPL-проекта должен деньги кому-то заносить, ЛООООООООЛ.

Даже для проприетарщины это не всегда так, кстати. LGPL (про которую и родился этот миф) нигде не запрещает статическую сборку. Она только накладывает условия распространения. Поставщик должен обеспечить возможность получателю сборки с другой совместимой версией Qt. ВСЁ. Один из способов это сделать описали в комментариях выше. Те, кого условия LGPL не устраивают, могут купить у троллей коммерческую версию, только и всего. И разумеется, это всё исключительно про распространение, для внутреннего употребления свободные исходники можно собирать как угодно.

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

Очередной слышавший звон, но абсолютно не понявший его сути. Я уже перестал удивляться.

А там ниже писал, что могу ошибаться. :-)

https://winlibs.com/

Оно не такое жирное как MSYS/Cygwin.

Нет, не предлагает. Библиотеки по системным или захардкоженным путям добавляют через target_link_libraries.

Ваше решение поставленной задачи?

Ну переползу на какой-нибудь симейк и? Что это доказывает? Чтоб доказать мне что симейк нужен, ты изменил задачу на ту, где симейк действительно нужен. Этак я тебе без труда докажу что в каждую тарелку борща нужно класть по киллограму соли (начальник поставил такую задачу: новенький Вася так любит) и? Как ты решишь поставленную задачу?

ты изменил задачу на ту, где симейк действительно нужен.

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

Ваше решение поставленной задачи?

А есть ещё более правильное решение: быть для начальника настолько полезным работником, чтоб он тебя слушал, а не наоборот

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

autotools / cmake / meson это всё одинаково ненужная блоатварь.

Так на каких системах сборки работают настоящие джедаи нынче? Просветите.

Понятие «система сборки» само по себе блоатварное. Это не то место, где нужны какие-то сложности, но недокодеры конечно их выдумают всегда и даже придумают пачку аргументов почему им вся эта муть обязательно нужна. Есть make - программа для парсинга мейкфайла и выполнения рецептов из него. У неё есть некоторые недостатки, но общая идеология её работы полностью правильная.

Тебя и EXL кто-то заставляет пользоваться cmake?

Есть make - программа для парсинга мейкфайла и выполнения рецептов из него. У неё есть некоторые недостатки, но общая идеология её работы полностью правильная.

Так мейк - и не система сборки. Более того, различные системы сборки умеют генерить мейк-файлы. Хотя нынче, в основном, генерят нинжу, по тому, что она быстрее работает.

Нет, без системы сборки, на голом мейке, тоже можно… При условии 1 единственной целевой системы, где ничего не меняется, все зависимости всегда на месте и их версии одни и те же всегда. Для хелло ворлда подойдёт.

Так мейк - и не система сборки.

Так и я о том. Блоатвари, которые приняты называть «системами сборки», не нужны, нужен парсер рецептов, коим является make.

на голом мейке, тоже можно… При условии 1 единственной целевой системы, где ничего не меняется, все зависимости всегда на месте и их версии одни и те же всегда.

Ну это наглое враньё. Либо профнепригодность. Единственная из мейнстримных ОС, где вообще всё не так - это винда (там и make обычно нет а есть всякие visual studio), для неё (если она нужна) можно сделать и файл проекта под vs. Всё остальное компилится примерно единообразно, а отличия между системами по месту делаются ifdef-ами и небольшим набором конфигов компиляции (не путать с той чушью, которую делают автотулзы, выясняя наличие в системе функции snprintf и подобного - это было актуально 40 лет назад).

Всё остальное компилится примерно единообразно, а отличия между системами по месту делаются ifdef-ами и небольшим набором конфигов компиляции

А либы искать тоже ифдефами? А кросс-компиляторы?

Причём тут либы?

Во-первых, по-нормальному - либы должны указываться в виде -llibname и они либо есть, либо их нет, «искать» будет компилятор. Да, pkgconf тоже не нужно.

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

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

Во-первых, по-нормальному - либы должны указываться в виде -llibname и они либо есть, либо их нет, «искать» будет компилятор.

А, ну ясно. То есть, вместо того, чтобы сказать юзеру «плиз инсталл зис либа энд трай агейн», вы заставляете своих юзеров рассматривать портянки ошибок компилятора или линкера, и решать проблему самому. Поздравляю.

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

Почему портянки то?

/usr/bin/ld: cannot find -lsomelib

что тут непонятного? Точно так же - установи библиотеку, и запусти ещё раз make, он продолжит с того же места. Хотя про отсутствующие инклюды и правда местами можно не понять из какого они продукта. Ну, проверить существование файлов по списку перед компиляцией и указать на те, которых не хватает - это очень простая вещь и явно не функционал для такого монстра, которым является cmake.

pthread_cancel

Я не отрицал что некоторые функции надо проверять. Даже на нормальных x86 системах не везде могут присутствовать такие обычные вещи как strlcpy() или explicit_bzero(). Но, опять же, это примитивная операция, явно не повод городить монстра как cmake. А так же не повод проверять то, что было актуально 40 лет назад, или то, что проекту не нужно, как делают автотулзы.

что тут непонятного?

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

А как на счёт опциональных зависимостей? Например, ну нету такой либы на данной системе, и поставить нельзя. «Отключить бы… но нет… у меня рукоядки такой» :)

Ну, проверить существование файлов по списку перед компиляцией и указать на те, которых не хватает - это очень простая вещь и явно не функционал для такого монстра, которым является cmake.

Да не, сам напишу скрипты, чо! :) «существование файлов по списку», ага, а в каком префиксе искать будете? На линуксе они в /usr, на бсде - в /usr/local. Ага: я заведу список потенциальных локейшнов, и буду по нему пробегаться… Ну и тд. :)

Даже на нормальных x86 системах не везде могут присутствовать такие обычные вещи как strlcpy()

Ну тоже, кстати. Где-то для неё надо делать -lbsd, а где-то и нет. И как быть?

явно не повод городить монстра как cmake

Да никто и не предлагает cmake! Мезоном пользуйтесь, 21 век на дворе.

что апстрим разделил либу на 2, и надо теперь с обеими линковаться? При чём, нормальный человек бы даже не заметил, ведь соответствующее изменение прилетело и в её .pc-файл тоже.

Делить либу на две чтобы потом обратно её собрать в одну pc-единицу - какое-то сомнительное действие. Ну да ладно, я всё равно уже написал как pkgconf использовать без блоатварных сборщиков.

А как на счёт опциональных зависимостей?

make вполне поддерживает приём аргументов, влияющих на процесс сборки.

в каком префиксе искать будете?

Искать будет компилятор, там же где и ищет при сборке. gcc -print-search-dirs Вручную никакие списки префиксов хардкодить не нужно, и их намного больше чем ты предложил.

Мезоном пользуйтесь, 21 век на дворе.

Ставить питон чтоб потом собирать проги на Си это бред.

Ставить питон чтоб потом собирать проги на Си это бред.

Не такой уж и бред. Почти на каждой *nix-like системе Python хоть какой-то версии уже установлен. На Windows его можно установить хоть с оффсайта, хоть с их недорепозитория/аппстора.

Этим и понравился waf. Работает он вплоть со самых старых легаси версий по самые современные. И ещё чтобы не делать pip install, который кстати опасно делать в Linux дистрибутивах, так как он (аналогично make install какой-то рандомной программы) превращает систему в Slackware, а venv на каждый чих создавать – это такое. =/

а venv на каждый чих создавать – это такое. =/

А pipx?

Хм! Не слышал о таком, спасибо за наводку.

pip install

В арче с недавнего времени это не работает. Pip ругается, что ты превращаешь систему в слаку и вместо этого нужно использовать venv. Я пока что отключаю это новое поведение через ключ ибо мне лень разбираться в питоновском мирке. Пусть будет слака.

Ну да ладно, я всё равно уже написал как pkgconf использовать без блоатварных сборщиков.

Привожу цитату: «Ну ладно, если без pkgconf тебе никак - можно его запустить пару раз перед сборкой хоть бы шелл-скриптом (сгенерировать переменные окружения для мейка) и дальше никаких проблем.» - то есть, мы руками, на основе пкгконфига, генерим Makefile.conf? А потом ещё вы ифдефами предлагали обкладываться, то есть и config.h мы тоже генерим, верно? Ну, видимо, лет 40 назад автотулзы примерно так и зарождались. :)

make вполне поддерживает приём аргументов, влияющих на процесс сборки.

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

Искать будет компилятор, там же где и ищет при сборке.

Так вы ж сами предлагали, перед сборкой, всё ж скриптиком поискать что-нибудь, хотя бы хедера… А теперь снова компилятор? :)

Ставить питон чтоб потом собирать проги на Си это бред.

Ну вот народ нашёл какой-то muon-meson, который пистона не требует. Правда и функционал последних мезонов он не даёт.

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

Возможно, но то было 40 лет назад. Тогда они может даже хорошим инструментом были. Но наслоения невыкидываемых легаси и потом наслоения мусорного кода для управления слоями мусорного легаси похоронили под собой возможную пользу. Ещё свой вклад внесло наркоманское m4 в основе - его никто не понимает и тупо копипастит у соседа, вместе с кучами ненужных действий.

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

Всмысле «сама отключить»? Это что за самодеятельность? Нет, «система сборки» должна спросить у юзера что ему нужно из фич, а потом уже на основе ответов выбрать зависимости. «Спросить что нужно» можно как раз через аргументы make. Если хочешь, можно интерактивный скрипт-конфигуратор для них сделать, такой есть в freebsd портах например - расставляешь галочки а потом по итогам генерится командная строка запуска сборки (кстати там никаких ни автотулзов ни тем более cmake не используется, всё через Makefile + спец утилита для рисования галочек - и работает намного быстрее перечисленной блоатвари).

Поведение «просто отключим то к чему нет либ» я видел у wine (во времена около версий 1.4, позже не интересовался) и оно весьма раздражало - приходилось ловить эти варнинги в логе чтоб вовремя понять каких либ не хватает, иначе придётся потом всё пересобирать.

Так вы ж сами предлагали, перед сборкой, всё ж скриптиком поискать что-нибудь, хотя бы хедера… А теперь снова компилятор? :)

Варианта два:

1) спрашиваем у gcc список путей к инклюдам и библиотекам, и ищем по ним сами

2) запускаем команду типа gcc dummy.c -lsomename и смотрим код возврата (да, похоже на автотулзы опять)

Ну вот народ нашёл какой-то muon-meson, который пистона не требует.

Замену meson на muon одобряю. Но на мой взгляд с этим всем с самого начала не надо было связываться.

Ещё свой вклад внесло наркоманское m4 в основе

Не буду комментировать м4 именно как основу автотулзов, но вот как препроцессор общего назначения - это мощная штука. На нём можно накодить практически всё, что угодно, но, при этом, он остаётся именно препроцессором. Альтернатив ему, среди препроцессоров, я не знаю.

Всмысле «сама отключить»? Это что за самодеятельность?

Как автор заложит, так она и сделает. Самодеятельности тут нет.

Нет, «система сборки» должна спросить у юзера что ему нужно из фич

Разумеется, если автор решит, что по этой фиче она должна спросить, а по вон той - можно и не спрашивать, то всё так и будет.

Если хочешь, можно интерактивный скрипт-конфигуратор для них сделать

Да нет, спасибо, я уж как-нить готовым воспользуюсь. :)

и оно весьма раздражало

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

Варианта два:

Да нет, не 2. :) Ещё - «использовать систему сборки» есть вариант. А вот писать скриптами свою - это как раз НЕ вариант.

Замену meson на muon одобряю.

А я нет. Он никогда не будет все возможности мезона поддерживать, всегда будет догоняющим. Потом его разрабам надоест делать пустую работу, чтобы только догнать основной мезон, и они на это забьют. Так как вкладывать в проект приличные усилия, при условии, что ничего нового и интересного ты не делаешь, а вынужден только за кем-то другим повторять - это сильно демотивирует, и долго они так не протянут.

…наркоманское m4… …его никто не понимает…

Ну вот не надо. Наркоманский — это язык CMake; m4 — это верх простоты. Не понимают его те, кто не удосужился хотя бы раз заглянуть в мануал. Ну, или те, кто заглянул, и, как в известном анекдоте, угадал все буквы, но не смог прочитать слово.

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

Я думаю, он имел в виду, «не понимают, зачем было писать на нём автотулзы». Как препроцессор, я его использую. Но когда я смотрю на автотулзы, то не особо понимаю, почему их надо было обязательно делать на препроцессоре. :)

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

Все непонимальщики, включая тебя, никогда не пытались читать мануалы от начала и до конца, хотя бы по диагонали.

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

Сборка на некоторой платформе с помощью гнушных автотулзов не предполагает, что на этой платформе есть гнушные автотулзы. Нужен какой-то Bourne-совместимый шелл и какой-то make. Не требуется именно гнушный шелл (баш), не требуется именно гнушный мейк, не требуется m4 (ни гнушный, ни любой другой), на котором, как ты говоришь, автотулзы написаны.

У тебя есть идеи, как можно сделать билдовую систему с такими требованиями? Подумай об этом. А мужики (я имею ввиду авторов автотулзов) на этом собаку съели: у них есть не только идеи, но и работающая реализация.

Если почитать ман, становится ясно какие цели стояли перед этим проектом и почему они получились именно такими.

Сборка на некоторой платформе с помощью гнушных автотулзов не предполагает, что на этой платформе есть гнушные автотулзы.

Это при условии, что проект тащит с собой сгенерённый конфигуре-скрипт на пару сотен килобайт, и плюс ещё кучу вспомогательных скриптов, типа config.guess, install-sh и тд. А так давно уже никто не делает. Все оставляют autogen.sh, но тогда - требуется и автоконф, и автомейк, и либтул.

А так давно уже никто не делает.

Вот только не надо безосновательных обобщений.

А так давно уже никто не делает. Все оставляют autogen.sh

У меня ровно обратная информация. Впрочем наличие мегабайтного configure совсем не радует.

А так давно уже никто не делает

Ещё как делают. Configure-скрипт готовый раза в два чаще встречается, чем autogen.sh

Посмотрю я на ваших юзеров, которые будут пытаться собрать там ваш говнокод мейком.

Друг, как человек, потративший 15 лет своей жизни, портируя свободное ПО на отличную от unix систему с ограниченным posix - а именно OpenVMS - я тебе скажу, что «проблема» с конфигурированием на такие системы - это детская шалость по сравнению с самим портированием. Симейки, автотулзы, ниньзи и прочая хрень это такая мелочь смешная… Даже написание своего конфигуратора - займет лишь маленькую толику твоих затрат. Поверь мне, у чувака-программиста Бионика совсем не о конфигураторе голова болит. И читать эти баталии фанатов конфигураторов на полном серьезе происходящие, просто смешно. Ребята просто не знают настоящих проблем.

Число комментариев: 404

Хехе

ограниченным posix - а именно OpenVMS - я тебе скажу, что «проблема» с конфигурированием на такие системы - это детская шалость по сравнению с самим портированием.

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

Так с OpenVMS пришлось портировать много чего. Интеловская версия появилась не сказать чтоб давно. А вот это гораздо большая проблема, чем наоборот.

На VMS портировать сильно проще, чем с VMS. :) У тебя в VMS какой-нибудь индексный файл тупо «иcкаропки» (ну да, РАБы-ФАБы :) ), а что делать бедному юниксоиду в этом случае? BerkelyDB прикручивать?

А либы искать тоже ифдефами?

Что значит искать либы?

А кросс-компиляторы?

А что с кросс-компиляторами?

мейк - и не система сборки

А что?

на голом мейке, тоже можно… При условии 1 единственной целевой системы, где ничего не меняется, все зависимости всегда на месте и их версии одни и те же всегда

На голом мейке все можно и предельно просто, для меня вообще загадка зачем кто-то что-то ещё использует