LINUX.ORG.RU

Какую систему сборки вы предпочитаете?

 , , , ,


1

5

В комментариях хотелось бы увидеть пояснение почему используете то или иное. Всем добра и что бы всё собиралось как надо ::)

  1. Makefile 316 (45%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. Cmake 236 (33%)

    **********************************************************************************************************************************************************************************************************************************************

  3. Не знаю, просто жму build в IDE 124 (17%)

    *****************************************************************************************************************************

  4. bash/sh/etc скрипты 109 (15%)

    **************************************************************************************************************

  5. qmake 99 (14%)

    ****************************************************************************************************

  6. Apache Maven 74 (10%)

    **************************************************************************

  7. Gradle 73 (10%)

    *************************************************************************

  8. Automake 58 (8%)

    **********************************************************

  9. Другой вариант (в комментариях) 56 (8%)

    ********************************************************

  10. Ninja 33 (5%)

    *********************************

  11. Своя система сборки 33 (5%)

    *********************************

  12. Meson 29 (4%)

    *****************************

  13. Qbs 25 (4%)

    *************************

  14. Apache Ant 13 (2%)

    *************

  15. Waf 8 (1%)

    ********

  16. SCons 6 (1%)

    ******

  17. imake 3 (0%)

    ***

Всего голосов: 1295, всего проголосовавших: 709

Deleted

Проверено: Licwin ()
Последнее исправление: Deleted (всего исправлений: 4)

Что значит предпочитаете? Есть стандарт, и это CMake. И да, лучше него ничего пока нет, и именно поэтому он стандарт.

slovazap ★★★★★
()

ZHLT

Zoner's Half-Life Tools (ZHLT) Version 3.

Jaga ★★★
()

qmake. Достаточно простой синтаксис, можно использовать и в не-qt-проектах (хотя последнее, согласен, извращение).

Ещё до анонса DoubleContact 0.1 я попытался перевести его сборку на cmake. Но через несколько дней я обнаружил, что вместо развития программы трачу основные силы на борьбу с cmake и отложил эту затею на неопределённый срок. При этом хотелки у меня совсем не чрезмерные: проект из двух целей, часть модулей должны включаться в обе цели в виде подпроекта, при этом сборка должна обеспечиваться как под Qt4, так и под Qt5. Если что, qmake это позволяет делать легко и лаконично, под cmake весь список требований я так и не осилил.

Для микропроектов из 2-3 файлов неплохой вариант - это простой Makefile. Но если программа тащит за собой что-то чуть более сложное, чем банальный glibc, и при этом должна собираться на разных платформах, он быстро утрачивает привлекательность. :)

В идеале хотелось бы иметь систему сборки с чётким декларативным синтаксисом и встроенным контролем оного. Но пока такого не видел.

hobbit ★★★★★
()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от slovazap

Есть стандарт, и это CMake. И да, лучше него ничего пока нет

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

hobbit ★★★★★
()
Ответ на: комментарий от Pravorskyi

Qbs — выглядит более интересно и перспективно, чем «генераторы Makefile»

Вот откуда такое мнение? Лично я считаю, что со своей задачей - сборкой по заранее построенному списку зависимостей и компиляторов - GNU make справляется отлично, и не нужно тут плодить велосипеды.

А вот построение этого списка логично возложить на другую программу, учитывающую специфику конкретного ЯП. Это как раз тот случай, когда unix way уместен. Можно на эту другую программу возложить и запуск make, это не противоречит написанному выше.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

сборкой по заранее построенному списку зависимостей и компиляторов - GNU make справляется отлично

Не так уж и отлично, раз появился ниндзя, который с этой задачей справляется объективно лучше. Просто, пока недостатки make себя особо не проявлялись, все им пользовались. Стоило гуглу под себя сделать ниндзю, тут и cmake сразу к себе его прикрутил, тут и специализированный meson появился.

redgremlin ★★★★★
()
Ответ на: комментарий от waker

уже тот факт что он на питоне должен вызывать отторжение.

Помнится проблевался радугой от необходимости питона для сборки V8 (это был не мезон, а GYP что ли) — видимо, да, отторжение :)

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

NIH синдром.

Всё правильно, если стандарт — говно.

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

You might say that CMake is ugly, but note that the CMake 2.x you might have tried is not the same CMake 3.x that is available today.

Нет. Он таким и остался. А с комплексом проблем с зависимостями, CMake тупо превратился autotools. И стал ещё хуже.

То, что выпинывают одно дерьмо и заменяют его другим, «немного получше» — это благо для развития IT. Я должен разрабатывать прикладной софт, а не бороться и подпирать костылями угрёбищный CMake.

Если его выпнут в конец отовсюду, то и скатертью ему дорога.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от EXL

Начиная с их ублюдочного регинстронезависимого синтаксиса IF if SET set ENDIF endif

Лечицсо полисями и конвеншонами, претензия из серии утячьих синдромов. Кто-то ровно так же от фигурных скобочек тошнит, кто-то — от вложенных :)

и заканчивая наркоманией с поиском библиотечных зависимостей

И что мы видим по твоей ссылке?

Отличный пример из жизни. Допустим, я хочу написать простейший HelloWorld, проигрывающий OGG-звук и отображающий PNG-изображение. Использовать буду современный SDL2 и сопутствующие либы как зависимости. Ну и сборочную систему CMake, конечно же.

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

CMake как бы говорит нам: иди-ка ты лесом.

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

Окей, что насчёт самой SDL2? Фух, разработчики положили туда Find-модули, проблема отпадает!

slackwarrior ★★★★★
()
Ответ на: комментарий от EXL

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

ой-вей, ну будешь подпирать другими костылями :) Я тебе уже написал почему

Если его выпнут в конец отовсюду, то и скатертью ему дорога.

хахахаха

slackwarrior ★★★★★
()
Ответ на: комментарий от slackwarrior

Лечицсо полисями и конвеншонами, претензия из серии утячьих синдромов

Круто, чо! Кроме полисей и конвеншинов по главному проектному языку, разработчик должен ещё париться составлением и выполнением требований по языку билд системы? Нет, это лечится нормальным и вдумчивым проектированием DSL-языка. В CMake об не думали, тяп-ляп и в итоге жидко обосрались под себя. В куче популярных проектов эта дрянь с разными регистрами и ладно бы в разных файлах, так нет в одном же!

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

Нехер было в начале делать по-другому.

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

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от slackwarrior

хахахаха

Пока ты хохочешь RedHat уже выпинывает. А скоро Google намается делать вот такие преколы с предподвывертом в своих сорцах:

https://github.com/googlesamples/android-ndk/blob/master/hello-libs/gen-libs/...

И тоже выпнет. А на мелочь всем пофиг, они накушаются и тоже уйдут.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Нехер было в начале делать по-другому.

Издержки развития :) Ты «ставши мужем, отринул младенческое»... или нет? Или «жил еще недолго»?

slackwarrior ★★★★★
()
Ответ на: комментарий от EXL

Меня редхат интересует вообще только с точки зрения «ну чо там еще Поттеринг отжог» А гугл с питоньими зависимостями сборки в плюсовых проектах еще тот авторитет «как надо» — именно они набирают пионеров с NIH синдромом :)

slackwarrior ★★★★★
()
Ответ на: комментарий от EXL

Проэкт который не передалывали, либо мертв, либо нафиг никому не нужен :)

slackwarrior ★★★★★
()
Ответ на: комментарий от iZEN

Потому что смешивать код и правила сборки это идиотизм? Для учебной фигни нормально но для чего-то серьезного не пойдет.

A-234 ★★★★★
()

cmake попробовал тут недавно (до этого жал build в IDE). Удобно, не напряжно.

sniper21 ★★★★★
()
Ответ на: комментарий от EXL

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

Да я смотрю тут полно грамотных проектировщиков, ну раз так, помогли бы?

sniper21 ★★★★★
()
Ответ на: комментарий от hobbit

Я понимаю, что GNU make создавался во время существования кучи Unix и Unix-like ОС, и нужен был мощный инструмент для создания правил сборок любой сложности с кучей условий и проверок.

Но сейчас мне GNU make кажется уже неоправданно сложным и многословным во многих типичных задачах. И тот же Qbs гораздо лаконичнее.

Ещё Qbs гораздо проще интегрировать в IDE и у него лучшая поддержка распараллеливания. Плюс модульная структура.

Я люблю Unix-way, но некоторые инструменты нуждаются в кардинальном реинжиниринге, IMHO.

Pravorskyi ★★★
()

Недавно spacex перевели ПО фалконов с мейкфайлов на bazel

pftBest ★★★★
()

Не нашел, что выбрать. Вариант «аштойта?» Уже предлагали добавить?

Pakostnik ★★★
()
Ответ на: комментарий от cvv

v8 уже давно собирается с помощью gn. По крайней мере при сборке chromium. А gyp там скоро отомрет, скорее всего.

alex_ac
()
Ответ на: А где sbt? от BattleCoder

Мастамела =)

Deleted
()
Ответ на: комментарий от Rodegast

Это не консольное приложение, по этому логично.

Хочешь сказать, если я ему пошлю SIGINT из какого-нибудь «Системного монитора», то поведение будет отличаться?

Softwayer ★★
()

Для Java единственная адекватная система сборки - это Maven (хоть он и не без недостатков: если есть какой-то нативный код или какой-то другой отход от канона (и нет плагина), то начинаются проблемы): переносимый между IDE, адекватная работа с зависимостями, конфиг достаточно написать 1 раз.

Ant: работал в компании в которой были конфиги на 5KLoC+, да и без Ivy, поэтому каждому новому разработчику нужно было тратить 1 день только лишь, чтобы запустить билд...

Gradle: из того, что я вижу, для pure-Java система не предлагает ничего полезно нового, зато сам конфиг нужно кодить (о да, отличная фича, Xzibit наверняка доволен), лог сборки довольно утомительно читать, да и использует пакеты из Maven, так что смысла в нем не особо много.

X-Pilot ★★★★★
()

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

KennyMinigun ★★★★★
()

Просто жму apt install. И вам советую.

one117 ★★★★★
()
Ответ на: комментарий от zabbal

Я бы сказал, что с момента появления autotools эта штука потеряла свою значимость :)

annulen ★★★★★
()
Ответ на: комментарий от EXL

На лицо — чудовищные огрехи в начальном проектировании.

Да не было никакого проектирования, переписали горстку m4-макросов на с++ и понеслась

annulen ★★★★★
()
Ответ на: комментарий от waker

Только вот у адекватных IDE под капотом те же системы сборки. А некоторые IDE ещё и позволяют выбрать из нескольких систем сборки. Это всего лишь оболочка.

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

hobbit ★★★★★
()

Все жрал кактус CMake. Наелся этого ущербного синтаксиса и ужасного поиска зависимостей.

Теперь хочется попробовать нормальную систему сборки. Думаю Meson попробовать.

Unicode4all ★★★★★
()
Ответ на: комментарий от sniper21

помогли бы?

В CMake уже ничего не исправить, его только на помойку.

EXL ★★★★★
()
Ответ на: комментарий от slackwarrior

он просто наелся CMake, попробовал адекватные альтернативы вот и рубит правду матку :)

Пофиксил.

EXL ★★★★★
()
Ответ на: комментарий от hobbit

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

и от этого она перестает быть сборочной системой?

waker ★★★★★
()
Ответ на: комментарий от EXL

он просто наелся CMake, попробовал адекватные альтернативы вот и рубит правду матку :)

Не, ты просто жил еще не долго, поэтому разборчив в сортах :) Щас подсядешь на «более лудшые» поделки — а потом выяснится, что у них фундаментальные недостатки — и придется упарываться новыми сортами субстанции.

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.