| 1.1, Аноним (-), 20:44, 22/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
из знающих, скажите -- чем это лучше чем напрямую напсать сценарий в Makefile ?
(думаю стоит начать учить или нет)
| | |
| |
| 2.2, Роман (??), 20:54, 22/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>из знающих, скажите -- чем это лучше чем напрямую напсать сценарий в
>Makefile ?
>
>(думаю стоит начать учить или нет)
IMHO, лучше учить CMake.
| | |
| |
| 3.6, Антон (??), 23:50, 22/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>IMHO, лучше учить CMake.
Плюсы CMake сводятся на нет размером и монстрообразностью. Для сборки проекта с autoconf в комплекте уже есть один скрипт configure в сотню килобайт, а для CMake нужно тянуть и ставить пакет в 20 Мб. IMHO, Cmake оправдан только для больших проектов, типа KDE.
| | |
| |
| 4.9, аноним (?), 02:20, 23/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Плюсы CMake сводятся на нет размером и монстрообразностью
Вы вообще понимаете о чем говорите? Нельзя придумать ничего глупее, как сравнивать Возможности cmake и какой-то там размер. Тем более что cmake очень легок, а монструозность - удел autocrap'а.
> для CMake нужно тянуть и ставить пакет в 20 Мб
cmake занимает 14MB, 5MB в пакете. Это в разы меньше того же gcc или python, если уж вы упомянули scons.
> Для сборки проекта с autoconf в комплекте уже есть один скрипт configure в сотню килобай
А вот это ложь.
- configure{,.ac,.in}
- Makefile.{in,am}
- {aclocal,acinclude}.m4, m4 (что кому нужно)
- Это все в КАЖДОМ пакете.
- Сами autoconf/automake, если надо собрать что-то из SVN или подправить что-то нетривиальное.
Например, из всех пакетов, что установлены у меня на десктопе, autocrap'овский мусор занимает не меньше 428MB.
| | |
| |
| 5.27, Bulgarin (ok), 19:38, 25/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
 Хренотень-с говорить изволите-с....
# pkg_info -s -x auto
Information for autoconf-2.62:
Package Size:
2559 (1K-blocks)
Information for automake-1.9.6:
Package Size:
1489 (1K-blocks)
| | |
| |
| |
| 7.39, Bulgarin (ok), 01:57, 26/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Разуйте глаза и перечитайте мой пост и что я считал.
А, ну да... Фокус не навел :)
# du -sh subversion-1.6.6/
49M subversion-1.6.6/
# du -sch subversion-1.6.6/configure* $(find subversion-1.6.6/ -name 'Makefile.[ai][nm]')
1,0M subversion-1.6.6/configure
35K subversion-1.6.6/configure.ac
31K subversion-1.6.6/Makefile.in
2,5K subversion-1.6.6/contrib/server-side/svnstsw/include/Makefile.am
...
1,1M total
# echo 1.1/49*100 | bc -l
2.24489795918367346900
Действительно, 2% - это серъезно.
| | |
|
|
|
|
| |
| 4.11, аноним (?), 02:36, 23/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Забыл добавить, что если вы хоть немного пишите на Python, то идеальный
>вариант - http://www.scons.org/
SCons мало что решает. Он не такой страшный выродок как autotools, но в смысле кастомизации, например, он еще хуже, потому что по умолчанию нет возможности даже указать CC/CXX/CFLAGS/CXXFLAGS/CPPFLAGS/LDFLAGS/PREFIX/..., он очищает окружение (так что ccache, например, пролетает). В смысле кросс-платформенности он вообще ноль, потому что для простейших вещей приходится писать кучу if'ов (особенно для зависимостей), и SCons{truct,cript} превращаются в помойку сравнимую с configure.
SCons годится разве что для использования внутри отдельно взятой конторы, где все условия заранее известны и важна повторимость билдов.
| | |
| |
| 5.13, Павел (??), 12:33, 23/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
plenv = Environment(CPPPATH = ["."])
plenv["CCFLAGS"] = "-DTEST_LEX"
Не врите. На сегодняшний день Scons превосходит ВСЕХ на голову.
Лично я же заинтересовался A-A-P (Брама Мулинаара).
| | |
| |
| 6.14, аноним (?), 15:54, 23/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> plenv["CCFLAGS"]
Снаружи, друг мой, снаружи. Через окружение или коммандную строку. Без правки SCons-файлов.
> На сегодняшний день Scons превосходит ВСЕХ на голову
Попробуйте доказать. Зависимости оно само ищет? Умеет генерить проекты для нескольких DE? Что-то хотя бы отдаленно похожее не ctest и cpack есть? Просто сравните сконструкты и симэйклисты от десятка проектов и посмотрите что короче и читабельней, а что состоит из кучи if sys.platform = .... Потом возьмите эти проекты и попробуйте без модификации собрать, например, на макоси и FreeBSD. Пока вы этим занимаетесь, банальные цифры по коллекции портов FreeBSD:
Портов, использующих cmake/scons: 171/38. cmake уже в разы популярнее.
Из них, портов, в которых упоминиются CMakeLists.txt/SCons(truct|cript) соответственно (что означает правки в системе сборки): 100/33. Т.е. 58%/87%, т.е. scons проекты требуют доводки гораздо чаще. А если внимательно посмотреть на патчи и их объем, SCons начинает выглядеть совсем жалко, ибо большинство патчей для CMakeLists - однострочная фигня типа правки директорий.
> Лично я же заинтересовался A-A-P
Сочувствую.
| | |
| |
| 7.26, Павел (??), 10:37, 25/11/2009 [^] [^^] [^^^] [ответить] | +/– | снаружи думаю, да раз он все-таки использует конструкцию os environ... большой текст свёрнут, показать | | |
| |
| |
| 9.40, Павел (??), 05:09, 27/11/2009 [^] [^^] [^^^] [ответить] | +/– | В итоге мы с вами пришли к выводу, что вам не хватает только make -DXXX Все ост... текст свёрнут, показать | | |
|
|
|
|
|
|
| 3.19, Аноним (-), 18:17, 23/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>IMHO, лучше учить CMake.
Не хочу ничего сказать но зависимости он обычно детектит горбато.
| | |
| |
| 4.22, аноним (?), 18:31, 23/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
В чем это выражается? По моему опыту это _единственная_ сборочная система, которая собирает софт из коробке на системах, где сторонние пакеты ставятся в отдельное место (/usr/local, /opt) и обычно требуют указания -I -L. cmake находит их влегкую.
| | |
|
|
| 2.3, аноним (?), 21:30, 22/11/2009 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> думаю стоит начать учить или нет
Не в коем случае, не тратьте время. autocrap - это autocrap.
Если приложение достаточно сложное и/или имеет много внешних зависимостей - CMake, без вариантов.
Если приложение совсем простое, можно обойтись простеньким Makefile. Для портабельности достаточно не использовать GNU Make - специфичные костыли, и оставить возможность переопределить любые переменные. Примерно так:
# Обратите внимание на ?= (не =)
CC?= gcc
CXX?= g++
# Обратите внимание на += (не =); никаких -O тут не надо - только то, что критично для успешной компиляции, нормальной работы и диагностики ошибок
CFLAGS+= -Wall -std=c99
CXXFLAGS+=-Wall
# Если используются внешние библиотеки, то так:
LDFLAGS?= #empty
CPPFLAGS?= #empty
LIBS= -lm -lpng -ljpeg
# разные системы смогут определить, например, CPPFLAGS=-I/usr/local/include и LDFLAGS=-L/usr/local/lib
a.o: a.c
${CC} ${CPPFLAGS}|${CFLAGS} -c a.c -o a.o
a: a.o
${CC} ${LDFLAGS} ${LIBS} a.o -o a
Такой Makefile будет работать без правки где угодно. Простое правило: если у вас в Makefile нужны .if/.ifdef/if/ifdef, используйте CMake.
| | |
| |
| 3.8, anonymous (??), 02:02, 23/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
У тебя банально не отслеживаются зависимости по хидерам: ты изменяешь хидер, а твой проект не пересобирается.
| | |
| |
| 4.10, аноним (?), 02:27, 23/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
>У тебя банально не отслеживаются зависимости по хидерам: ты изменяешь хидер, а
>твой проект не пересобирается.
У меня, если вы не заметили, вообще нет хидеров.
| | |
|
|
| 2.5, Хоменко (ok), 22:58, 22/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Я не шибко знающий (два проекта средней сложности), но имею вот что сказать.
Писать с нуля свои Makefile.am и configure.in -- такой ежедневный подвиг совершенно напрасен. Число и, главное, разнообразие ваших пректов малы и заурядны и никак не требуют знания всех нюансов autotools наизусть -- вы же не пишете новый, совершенно не похожий на предыдущий configure.in дважды на день? Потому достаньте какой-нибудь прожект сходных зависимостей и... ны вы поняли. Это ж опенсорц, елы-палы, а стесняется пусть оригинальный автор качеством свего кода, а не вы.
Другими словами, я особенно не рвусь отстаивать весьма замысловатый синтаксис и структуру autotools, но просто замечаю, что им лет пятнадцать уже, и если они существуют до сих пор, то уж наверное не зря.
Вон, аналогичным образом мысля, если решить не приступать к работе с emacs'ом, предварительно не выучивши все его цепочки и трещинки, то вы не приступите к работе с emacs'ом вообще никогда.
А относительно CMake -- надо будет посмотреть, интересно.
| | |
| |
| 3.12, Serg (??), 03:14, 23/11/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Писать с нуля свои Makefile.am и configure.in -- такой ежедневный подвиг совершенно напрасен
Вот именно. И вы думаете что ситема, где написание скрипта для сборки простейшего проекта с нуля считается подвигом, достоина существовать?
> но просто замечаю, что им лет пятнадцать уже, и если они существуют до сих пор, то уж наверное не зря
Знали бы вы сколько дерьма существует в этом мире "наверное не зря". То, что свечи существуют очень долго и тоже наверное не просто так, совешенно не аргумент против использования электричества.
> А относительно CMake -- надо будет посмотреть, интересно
Обязательно посмотрите.
| | |
| |
| 4.21, Аноним (-), 18:20, 23/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Вот именно. И вы думаете что ситема, где написание скрипта для сборки
>простейшего проекта с нуля считается подвигом, достоина существовать?
Можно прошибать все стены своим лбом, как проприетарщики. А зачем? В опенсорс гордая независимость и самодостаточность нафиг не нужны. Коллективный разум - решает.
| | |
| |
| 5.24, аноним (?), 18:34, 23/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Можно прошибать все стены своим лбом, как проприетарщики. А зачем? В опенсорс
>гордая независимость и самодостаточность нафиг не нужны. Коллективный разум - решает.
Можно не прошибать стены лбом - использовать удобные инструменты и не использовать неудобные. Но не все, видимо, ищут легких путей.
| | |
| |
| 6.50, User294 (ok), 21:23, 01/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Я бы не стал с нахрапом утверждать что установка какого-то добавочного пакета + гемор с глюками - проще чем запуск 1 шеллскрипта, проверенного временем. Хотя, конечно, если вам похрену кто и где осилит компилежку вашей программы - вперед на мины :).
| | |
|
|
|
|
| 2.16, Аноним (-), 17:34, 23/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> из знающих, скажите -- чем это лучше чем напрямую напсать сценарий в Makefile ?
autoconf нужен только для того, чтобы определить какие фичи на платформе доступны. Например, какой версии ncurses стоит, есть ли поддержка SCTP, ACL, MAC, умеет ли компилятор LTO, использовать ли OpenSSL или GnuTLS и так далее.
Если портируемость на другие ОС не важна, то иногда можно ограничиться ifdef'ами на основе вывода компилятора и версии самой ОС.
$ cc -march=native -dM -E - </dev/null
На *BSD системах, например, automake можно заменить на bsdmake, т.к. на этих системах есть пачка готовых сценариев в /usr/share/mk/
| | |
|
| 1.4, аноним (?), 21:52, 22/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
autotools стали не нужны после появления cmake. И извините, но костыли из макросов которые генерят скрипт на полметра для проекта из двух строчек были дикостью с момента своего появления. Надеюсь, ни в одном новом проекте я их больше не увижу, да и старые от них откажутся.
| | |
| |
| 2.28, Bulgarin (ok), 19:47, 25/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>autotools стали не нужны после появления cmake. И извините, но костыли из
>макросов которые генерят скрипт на полметра для проекта из двух строчек
>были дикостью с момента своего появления. Надеюсь, ни в одном новом
>проекте я их больше не увижу, да и старые от них
>откажутся.
И теперь, что бы откомпилировать пять строк, я должен тянуть этот лядский монстроидный cmake? Вместо того что бы воспользоваться заранее сгенерированым Makefile? :)
| | |
| |
| 3.30, аноним (?), 19:50, 25/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
Сгенерированный чем? autotools? Так он работать не будет.
Ради пяти строк я, так и быть, разрешаю вам написать свой Makefile.
| | |
| |
| 4.34, Bulgarin (ok), 21:26, 25/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Сгенерированный чем? autotools? Так он работать не будет.
>Ради пяти строк я, так и быть, разрешаю вам написать свой Makefile.
От какой добрый :)
Написать пять строк в Makefile.am, десяток в configure.in
потом пройтись automake/autoconf, что бы мне потом только запустить configure - не, это не кошерно.
А вот наплевать на других, пусть тащат монстроидный cmake, собирают, правят его правила под систему, натравливают на проект - это запросто.
Это называется human friendly development :)
| | |
| |
| 5.35, аноним (?), 21:59, 25/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Написать пять строк в Makefile.am, десяток в configure.in
>потом пройтись automake/autoconf, что бы мне потом только запустить configure - не,
>это не кошерно.
Я уже сказал что плюсов тут никаких нет - места это жрет в десятки раз больше cmake (если у вас в системе не один пакет), правок требудет больше, а правится гораздо сложнее. Еще раз - ради пяти строчек напишите банальный Makefile - пример я привел, не заставляйте людей качать мегабайты нечитаемых скриптов. Это human friendly. Если банального Makefile не хватает - возьмите cmake, и не заставляйте людей качать мегабайты нечитаемых скриптов и править мегабайты нечитаемых скриптов. Это human friendly.
>А вот наплевать на других, пусть тащат монстроидный cmake, собирают, правят его
>правила под систему, натравливают на проект - это запросто.
Вы cmake в глаза не видели, да и Linux тоже, похоже.
| | |
| |
| 6.37, Bulgarin (ok), 00:58, 26/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>А вот наплевать на других, пусть тащат монстроидный cmake, собирают, правят его
>>правила под систему, натравливают на проект - это запросто.
>
>Вы cmake в глаза не видели, да и Linux тоже, похоже.
# ls -lh /usr/distfiles/cmake-2.6.4.tar.gz
-rw-r--r-- 1 root wheel 3,1M 28 апр 2009 /usr/distfiles/cmake-2.6.4.tar.gz
# cmake --version
cmake version 2.6-patch 4
# find /usr/local/share/cmake/ -type f | wc -l
377
# pkg_info -s -x cmake
Information for cmake-2.6.4:
Package Size:
17626 (1K-blocks)
# rlog ~/.bashrc | tail -5
revision 1.1
date: 1997/10/16 14:44:50; author: root; state: Exp;
Initial revision
----------------------------
Это все с нетбука, с которого этот пост.
Правила cmake приходилось править неоднократно.
Если бы не знал, то и не писал.
| | |
| 6.48, User294 (ok), 21:17, 01/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Это human friendly.
Да, зато когда придется этот самый cmake компилячить где-нить - это уже совсем не human friendly. Не говоря о том что зависимости и конфигурацию он проверяет крайне своеобразно, глючит через раз и ломается так что иной раз весь мозг свихнешь пока что-то с оным скомпилишь. Видел несколько прог где конфигур и cmake параллельно пользуются. И если конфигур обычно остреливается без проблем (какие-то глюки я видел 1 раз в жизни) то cmake - доезжает до финиша без приключений или с внятным отлупом спасибо если через раз. Итого - на данном этапе развития человечества при прочих равных я предпочту прогу у которой система сборки на основе автотулзов. Гемора с компилежкой как-то меньше.
| | |
|
|
|
|
|
| 1.18, Otall (?), 17:47, 23/11/2009 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Ну нужен. Все вменяемые люди давно свалили на cmake. Кое-кто на убожество scons, но потом все равно на cmake.
| | |
| |
| 2.29, Bulgarin (ok), 19:48, 25/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Ну нужен. Все вменяемые люди давно свалили на cmake. Кое-кто на убожество
>scons, но потом все равно на cmake.
А вменяемый - это вы лично?
| | |
| |
| 3.36, аноним (?), 22:07, 25/11/2009 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>А вменяемый - это вы лично?
Ну уж явно не человек, который не может поставить 3MB пакет, которым уже собирается куча софта из-за причин, которые он затрудняется назвать.
| | |
| |
| 4.38, Bulgarin (ok), 01:19, 26/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>>А вменяемый - это вы лично?
>
>Ну уж явно не человек, который не может поставить 3MB пакет, которым
>уже собирается куча софта из-за причин, которые он затрудняется назвать.
# pkg_info -s -x cmake-2.*
Information for cmake-2.6.4:
Package Size:
17626 (1K-blocks)
# cd /usr/bsdports
# grep -l 'USE_CMAKE' devel/*/Makefile net*/*/Makefile www/*/Makefile | wc -l
25
# grep -l 'GNU_CONFIGURE' devel/*/Makefile net*/*/Makefile www/*/Makefile | wc -l
1090
То есть на какой-нить HPUX мне придется для откомпилировать софтинку тянуть-компилировать еще и cmake?
Ибо у него правила проверки не инкорпорирированы, как в configure, а отдельно?
# ls -1 /usr/local/share/cmake/Modules | wc -l
280
Учитывая что он на с++, то встретить кучу косяков на ровном месте...
# du -sh cmake-2.6.4/Source/
8,2M cmake-2.6.4/Source/
Или опять - на свете есть только любимый Linux, и нет иного?
| | |
| |
| 5.44, аноним (?), 03:41, 28/11/2009 [^] [^^] [^^^] [ответить]
| +/– |
>То есть на какой-нить HPUX мне придется для откомпилировать софтинку тянуть-компилировать еще
>и cmake?
Представьте себе, также как и autotools, gcc, make и тулчейн.
>Ибо у него правила проверки не инкорпорирированы, как в configure, а отдельно?
>Учитывая что он на с++, то встретить кучу косяков на ровном месте...
Далее следует феерический неаргументированный бред, с приведением каких-то размеров и количест файлов.
>Или опять - на свете есть только любимый Linux, и нет иного?
Во-первых, если вы не заметили, у меня не Linux. Во-вторых, ИМЕННО, что есть иное, и на этом ином autotools и scons требуют на порядок больше геморроя, чтобы собрать софт.
| | |
|
| 4.41, Аноним (-), 21:24, 27/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Ну уж явно не человек, который не может поставить 3MB пакет,
Знаете, не у всех людей есть root на машинах, где они работают.
Бывают, к примеру, конторы, использующие линукс и рута не любят давать.
| | |
| |
| 5.43, аноним (?), 03:37, 28/11/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Знаете, не у всех людей есть root на машинах, где они работают.
И что? cmake можно также поставить из-под юзера.
| | |
| |
| 6.49, User294 (ok), 21:20, 01/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>И что? cmake можно также поставить из-под юзера.
А у автотулсов насколько я помню - как правило вообще ничего не надо ставить на target-е. Просто пинаем конфигур и усе. Как-бы есть некоторая разница между изгалениями по поводу установки чего-то там куда-то там и простым запуском шелл-скрипта.
| | |
|
|
|
|
|
|
