LINUX.ORG.RU

autotools, Ъ, олдскульно и канонично, все их используют

Harald ★★★★★ ()

cmake или чистый make. Автолулз зачастую неюзабелен и весьма криво ведёт себя с кодом от других версий.

anonymous ()

make. Местами конечно приходиться изголяться (рекурсивные вызовы, шаблонные правила), но вещь годная.

AIv ★★★★★ ()

autotools, хотя да, надо бы сваливать на CMake.

O02eg ★★★★★ ()

cmake

Поддерживает вижуальник и вижуальниковый нативный компилятор, поддерживает эклипс и гцц, поддерживает кросс-компиляцию.

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

Manhunt ★★★★★ ()

смотрю в сторону cmake

Ну и всё, смотри и вкуривай дальше

AlexVR ★★★★★ ()

cmake. очень удобная вещь.

unfo ★★★★★ ()

CMake - это не система сборки, а генератор Makefile'ов и тд.

JackyTreehorn ()

таки пользую make. сила привычки)

ymn ★★★★★ ()

остановлюсь на cmake. всем спасибо

staz ()

Использую CMake. Потому что это первое, что осилил.

CMake не устраивает тем, что не приучает ни к какому из стандартов. Те же autotools соответствуют GNU-стандарту для системы сборки (предоставление целей dist, distclean, check, ...), хотя многим (и мне) autotools кажется сложнее CMake.

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

В общем, сам я постоянно думаю о других системах сборки, но с CMake как-то пока живу.

jeuta ★★★★ ()

для опенсорс проектов использую autotools, потому что на все случаи жизни есть готовые макросы, и куча проектов где подсмотреть как что делать. ну и потому что юзеру кроме make для сборки не надо никакие cmake/qmake/scons/python и пр. устанавливать, и разбираться как их запускать. но порог вхождения для девелопера высок, и граблей немало, которые придется учиться обходить.

для очень мелких проектов просто make. потому что просто и быстро.

кроссплатформенного не бывает — везде что-то надо допиливать, или вообще использовать специальные системы сборки (например, на ведроиде).

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

под кроссплатформенностью я подразумевал линукс, мак и венду.

staz ()

autotools во все поля, если сборка не умещается в одну строку (cc -o prog *.c)

r2d2 ()

Господа, современные autotools очень просты, особенно с non-recursive make

autoscan всё сделает за вас, синтаксис Makefile.am поймёт даже дебил, а libtool позволит забыть про туеву хучу компиляторов и линкеров. И у вас всегда есть возможность воспользоваться грубой силой под названием shell code.

r2d2 ()

make или qmake, в зависимости от размера и нужна ли портабельность.

nanoolinux ★★★★ ()

cmake — просто и кроссплатформенно.

если действительно нужна кроссплатформенность, то на autotools смотреть даже не надо, ибо это gnu-only поделка.

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

и как у libtool'а обстоят дела с cl.exe? а еще расскажи как использовать это поделие если в системе нет sh и gmake

Reset ★★★★★ ()

Используйте cmake.

Я сам пишу либо простые makefile'ы, либо простые mkfile-ы :) Но у меня каких-то диких деревьев исходников нет.

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

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

staz ()
Ответ на: комментарий от Reset

и как у libtool'а обстоят дела с cl.exe?

Нормально обстоят, говорят.

а еще расскажи как использовать это поделие если в системе нет sh

Поставить sh? 8))

и gmake

Ну с BSD make оно таки работает. С какими-то более другими тоже, типа чпуксовского.

Вообще autocrap былинно гибок, но за пределами unix-like с ним ловить нечего от слова совсем.

kemm ()

Maven. Еще ant хорош. Можно и msbuild/xbuild использовать.

anonymous ()
Ответ на: комментарий от kemm

Колотить. gmake не нужен для automake, он генерирует совершенно тупые make-файлы, и грязно ругается, если в Makefile.am есть что-то непортируемое.

Не знаю как CL (common lisp?), но libtool - первую очередь для сборки библиотек из C, C++ и Fortran - в общем, всё, что компилируется. А для остальных языков (perl, python, node.js, etc) есть специализированные средства - и это правильно.

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

Колотить. gmake не нужен для automake

А я что написал? Нет, я понимаю, что читать на лоре не модно изначально, но не до такой же степени.

он генерирует совершенно тупые make-файлы

Которые nmake всё равно не поймёт, ага? Насколько я помню, добавление его поддержки загнулось на этапе обсуждения со словами «nmake на винде — не самая большая проблема с автотулами. Если уж надо ставить sh, sed, awk и тонну всякого — то поставить gmake тем паче не проблема». Напоминаю, что году так в 2001, например, в automake не было поддержки BSD make.

Не знаю как CL (common lisp?), но libtool - первую очередь для сборки библиотек из C, C++ и Fortran - в общем, всё, что компилируется

С чего вдруг cl.exe (не CL, а cl.exe) ВНЕЗАПНО стал лиспом-то?

kemm ()

CMake. И кроссплатформенный, и к гнутому тулчейну не привязан (или я из анабиоза вышел, и autotools тоже не привязаны?).

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

и как у libtool'а обстоят дела с cl.exe?

Нормально обстоят, говорят.

Нормально, это как? И кто говорит? В MSVC можно будет открыть все это добро сгенерированное из autotools и пользоваться удобствами вроде Visual Assist и запуска под отладчиком?

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

Дак, Резету много чести отвечать :-)

С чего вдруг cl.exe (не CL, а cl.exe) ВНЕЗАПНО стал лиспом-то?

Вендузятников хрен разберёшь.

r2d2 ()
Ответ на: комментарий от kamre

И накой сдались все эти Ассисты? Если вам нужны могучие тулзы для написания кода, то тут два правильных варианта:

1. На самом деле вам нужен кодогенератор (flex, perl, awk, wtf)

2. Вам нужен другой язык.

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

А что в этом удивительного? Довольно удобно разрабатывать в MSVC, а собирать и тестировать еще под linux. CMake это легко позволяет делать.

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

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

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

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