LINUX.ORG.RU

Чем собираете нативный код?

 , , ,


2

4

Вопрос про систему сборки. Какими из перечисленных Вы предпочитаете пользоваться / используете в «продакшене»?

  1. GNU Make 494 (51%)

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

  2. CMake 444 (46%)

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

  3. Qmake 162 (17%)

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

  4. Autotools 138 (14%)

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

  5. Простой (свой) скрипт сборки (bash, batch, ...) 114 (12%)

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

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

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

  7. Maven 63 (6%)

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

  8. Ninja 53 (5%)

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

  9. nmake (Visual Studio) 46 (5%)

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

  10. Gradle 43 (4%)

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

  11. BSD Make 37 (4%)

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

  12. QBS 21 (2%)

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

  13. Своя системя сборки (аля flower в Opera) 18 (2%)

    ***********

  14. Scons 17 (2%)

    ***********

  15. Premake 4 (0%)

    **

  16. Tup 2 (0%)

    *

Всего голосов: 1735, всего проголосовавших: 971

★★★★★

Проверено: jollheef ()

make
В опрос надо добавить вариант «Встроенная в IDE»
Например, xcode и visual studio предоставляют свою систему сборки для проектов и у vs это не nmake

mittorn ★★★★★
()

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

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

Ну, вопрос про нативный код, потому Java/C# — не релевантны. Добавил Maven и Gradle только потому, что они умеют собирать C/C++ (может кто-то так извращается).

KennyMinigun ★★★★★
() автор топика

GNU Make

Интересно, собирает ли кто-нибудь tup-ом.

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

тем, что использует собираемый проект.

Тогда вопрос буде звучать «что использует собираемый проект?»

предпочтения варьируются в зависимости от ... языка программирования

Вопрос про языки, которые компилируются в нативные бинарники: т.е. в основном С и C++. А Java, C#, Managed C++, Python и подобные — «out of scope».

Ибо понятно, что для каждой платформы свойственны свои системы сборки. Т.е. меня именно интересует что сейчас в «тренде» для «нативной» группы языков.

на работе у нас вообще своя система сборки написанная на C#.

Если она собирает нативныq код, то «Своя системя сборки (аля flower в Opera)».

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

В опрос надо добавить вариант «Встроенная в IDE»

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

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

ну предполагается что если человек не разбирался что юзает ide то выберет его. И обычно это означает безразличие к тому какая система сборки

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

Вопрос про языки, которые компилируются в нативные бинарники: т.е. в основном С и C++.

тем не менее, их больше чем 2, и от этого нередко зависит выбор системы сборки.

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

Тогда вопрос буде звучать «что использует собираемый проект?»

из того с чем сталкивался за последние лет 5:

make, jam+, gradle, как минимум 2 кастомных системы сборки, автотулсы, встроенные в вижуалы и хакод, и наверняка еще столько же забыл.

waker ★★★★★
()

Make, а что-то сложнее пока не пригождалось.

olibjerd ★★★★★
()

CMake и Android.mk для С/С++. Ant для Java.

А вообще все эти ваши мейкфайлы — одноразовый продукт. Их писать самому нужно крайне редко, разве только если вы пишете систему сборки или просто другого не дано. Я лично в своих Makefile всегда пишу, что работает только под GNU Make, что я плевал на то, какая у вас реализация. Потому что зоопарк не нужен.

a1batross ★★★★★
()

CMake
GNU Make
Autotools
Qmake
Gradle
ant

Это юзаю. А ещё забыли про Jam, если я правильно помню, то MuPDF и Boost используют (использовали) именно его.

EXL ★★★★★
()

Ещё waf не хватает в списке.

olibjerd ★★★★★
()

Нет cargo в вариантах, тоже умеет собирать нативный код.

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

Тогда вопрос буде звучать «что использует собираемый проект?»

Который из? Плюсуюсь к комментарию ув. тов. waker про то, что сборка определяется проектом, платформой, языком, фреймворком, а проектов и всего остального может быть много.

И да, я собирал нативный код из-под Gradle, вроде живой :-) На самом деле это не на столько редкий случай на Android.

Aceler ★★★★★
()

GNU Make кажется многозначительным: ведь если использовать autotools, то в результате сборка происходит через make. С Qmake и в большинстве случаев Cmake аналогично. Если же под GNU Make имеется ввиду самописный Makefile, то лучше бы так явно и указать (аналогично «простой (свой) скрипт сборки»).

gag ★★★★★
()

Не хватает waf

nmake - имеет смысл добавить jom (мультипоточную версию)

Не хватает MSBuild (простите за богохульство, но nmake то есть)

Не хватает проектных файлов ide, аля cdt или code::blocks.

В порядке приоритета: CMake, ninja, gnu make, nmake/jom, autotools

pon4ik ★★★★★
()

GNUMake/CMake, хотя подумываю об использовании Rake

Ancient
()

eclipse нет в вариантах... (я не использую его, просто заметил)

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

имеет смысл добавить jom

Удваиваю.

Не хватает MSBuild

Утраиваю.

LamerOk ★★★★★
()

Нет варианта: не собираю нативный код.

Xunnu ★★
()

Пишу на интерпретируемом языке.

lochness
()

Что используется, тем и собираю. Сам люблю gradle для Java и Cmake для всего остального, C# собираю в студии под оффтопиком.

peregrine ★★★★★
()

GNU Make, изредка, когда приходится пересобирать код под оффтопик - nmake. Не вижу смысла лично для себя в чем-то другом.

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

Ну, вопрос про нативный код, потому Java/C# — не релевантны

Не знаю насчет Java, но C# возможно собирать нативно.

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

может кто-то так извращается

Когда нужно интегрировать в проект на яве нативный код (библиотеку, например), которая уже собирается каким-нибудь cmake'ом. cmake-maven-plugin - и понеслась...

AlexM ★★★★★
()

Только CMake, все остальное для негров.

MuZHiK-2 ★★★★
()
Ответ на: комментарий от ZenitharChampion

А ты откуда знаешь?

Предположил. [irony]Все равно проверить никак.[/irony]

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

где вариант «использую только компилятор и линковщик всё остальное от лукавого»?

вот же:

Простой (свой) скрипт сборки (bash, batch, ...)

... просто он вводится в консоли (может даже алиасами)

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

Ну вообще да, но я бы не скрещивал мяч с чемоданом. Ато все итак уже сложно. А я всего лишь хотел узнать что сейчас в тренде для С/C++ (может так изначально стоило мне и писать? :)).

KennyMinigun ★★★★★
() автор топика

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

rupert ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.