Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 59
Спасибо за информацию
Спасибо. Новичкам будет очень полезно, особенно когда начинаешь задумываться, а как же на самом деле правильно организовать проект.
Разжевал — спасибо :-)
Спасибо, но я за cmake
Пожалуйста, разработчики, НИКОГДА не используйте самописные makefile-ы. Это pain in the ass в поддержке, и для любого, кому понадобится их читать. Используйте CMake, или на худой конец autotools.
Что у autotools, что у CMake стандартизированный набор параметров, которые они принимают при конфигурировании, с которыми достаточно разобраться один раз, и потом каждый проект на них будет казаться вам чем-то знакомым. У самописных мейкфайлов — чёрт знает что, каждый раз разное, и не всегда корректно работающее на различных конфигурациях, с различными компиляторами, с различным расположением внешних зависимостей, и т.д.
Мало того, CMake позволит вам ещё и нормально использовать IDE при работе с кодом (Qt Creator, KDevelop).
Что у autotools, что у CMake стандартизированный набор параметров, которые они принимают при конфигурировании, с которыми достаточно разобраться один раз, и потом каждый проект на них будет казаться вам чем-то знакомым. У самописных мейкфайлов — чёрт знает что, каждый раз разное, и не всегда корректно работающее на различных конфигурациях, с различными компиляторами, с различным расположением внешних зависимостей, и т.д.
Мало того, CMake позволит вам ещё и нормально использовать IDE при работе с кодом (Qt Creator, KDevelop).
Конечно, сейчас использовать make стоит только для маленьких (из пары-тройки исходных файлов) проектов или для развлечения. Если же пытаться применить make к чему-то большему, то в итоге получится тот же autotools или CMake, только вот с наполовину меньшим функционалом и кучей ошибок.
make — универсальная утилита. cmake и autotools — специально заточены для C и C++, они не покрывают всех сценариев использоания make.
Они расширяемы.
Вы предлагаете мне расширять не связанную с текущим проектом систему вместо того чтобы взять make и делать дело? cmake и autotools не вчера появились. Если бы кто-нибудь положительно оценил их для использования с другими языками, их бы уже расширили.
Вот CL был оценен как язык для веб и на нём сразу появились и веб-сервера и фреймворки. :]
Вот CL был оценен как язык для веб и на нём сразу появились и веб-сервера и фреймворки. :]
поддерживаю. недавно перевёл свой проект (не большой, около 60 c/cpp файлов и около 100 h), первое впечатление — лучше бы оставил на make.
make-файл я написал часа за пол, ещё столько же понадобилось чтоб он нормально заработал на freebsd и pegasos (странная amiga с ppc процессором).
в случае с cmake я убил пол дня только на то, чтобы убедить cmake препроцессить некоторые .c файлы специальнам препроцессором (ну… так надо).
make простой как топор — собственно как и все classic-unix утилиты.
cmake сверх мощный и очень сложный. мне он напоминает продукты Microsoft — стандартные вещи делаются в пол строчки, но если надо что-то нестандартное, готовтесь потратить пол дня (а то и больше).
make-файл я написал часа за пол, ещё столько же понадобилось чтоб он нормально заработал на freebsd и pegasos (странная amiga с ppc процессором).
в случае с cmake я убил пол дня только на то, чтобы убедить cmake препроцессить некоторые .c файлы специальнам препроцессором (ну… так надо).
make простой как топор — собственно как и все classic-unix утилиты.
cmake сверх мощный и очень сложный. мне он напоминает продукты Microsoft — стандартные вещи делаются в пол строчки, но если надо что-то нестандартное, готовтесь потратить пол дня (а то и больше).
Судя по полученным минусам кто-то успешно использует cmake или autotools для всех своих проектов, независимо от языка разработки. Сделайте же бескорыстное доброе дело — поделитесь знанием.
Верно. Для полноты картины добавлю, что есть еще QMake и PreMake. Лично мне очень понравился PreMake, потому что используется стандартный скриптовый язык Lua.
PreMake выглядит интересным.
Насчет расширяемости CMake я бы так не спешил говорить. Как раз пытаюсь добавить Vala support в CMake и если честно то я не очень впечатлен внутренностями cmake. BASIC-like синтаксис для макросов с кучей variables бррр Довольно сложно читать этот код.
Насчет расширяемости CMake я бы так не спешил говорить. Как раз пытаюсь добавить Vala support в CMake и если честно то я не очень впечатлен внутренностями cmake. BASIC-like синтаксис для макросов с кучей variables бррр Довольно сложно читать этот код.
Рыская по просторам интернета нашел еще один интересный build tool
gittup.org/tup/make_vs_tup.html
Отличительная способность — быстрый incremental build. Использует inotify + sqlite где хранит граф зависимостей.
gittup.org/tup/make_vs_tup.html
Отличительная способность — быстрый incremental build. Использует inotify + sqlite где хранит граф зависимостей.
Если писать Makefile правильно, используя %.o: %.c, то всё будет аналогично и при использовании make. И судя по описанию файл tup'а можно по простым правилам преобразовать в Makefile.
Фишка Tup не в синтаксисе (он очень близок к Makefile) а в том как эффективно он собирает incremental builds. Почитайте по ссылке что я привел — не пожалеете.
> И судя по описанию файл tup'а можно по простым правилам преобразовать в Makefile.
Вы хотели сказать *ИЗ* Makefile?
Хотя я нашел Tup только лишь пару дней назад — мне он очень нравится. Уже собрал LLVM/Clang/Bison этой тулзой. Работает великолепно.
pomozok.wordpress.com/2011/01/13/66/
> И судя по описанию файл tup'а можно по простым правилам преобразовать в Makefile.
Вы хотели сказать *ИЗ* Makefile?
Хотя я нашел Tup только лишь пару дней назад — мне он очень нравится. Уже собрал LLVM/Clang/Bison этой тулзой. Работает великолепно.
pomozok.wordpress.com/2011/01/13/66/
Я прочитал, прежде чем говорить :) На первый взгляд магии не видно и автор сам говорит о том, что вариант с Makefile был некорректным. Про корректность варианта с Tup ни слова. Да и в целом тест выглядит довольно синтетически, никто не будет использовать в проекте 10000 файлов разложенных по сбаллансированному дереву.
Не совсем понял в чем синтетичность теста. То есть если разбросать файлы случайным образом (разное количество в разных папках) то Make сразу же быстро заработает? Сильно в этом сомневаюсь.
Пример работы Tup — инкрементная сборка Linux distro (похожая на Gentoo) gittup.org/gittup/
[marf@captainfalcon gittup]$ vi nethack/src/spell.c
[marf@captainfalcon gittup]$ vi busybox/coreutils/ls.c
[marf@captainfalcon gittup]$ time tup upd -j2
Executing Commands
[ 0/9 ] busybox/coreutils/CC ls.c
[ 1/9 ] nethack/CC src/spell.c
[ 2/9 ] busybox/coreutils/LD built-in.o
[ 3/9 ] busybox/LD busybox
[ 4/9 ] nethack/LD nethack
[ 5/9 ] initrd/bin/CP busybox
[ 6/9 ] initrd/bin/CP nethack
[ 7/9 ] initrd/MKINITRD
[ 8/9 ] initrd/GZIP initrd
[ 9/9 ]
real 0m1.571s
user 0m1.888s
sys 0m0.269s
Полторы секунды. Вот это я и подразумеваю быстрая инкрементрая сборка. gmake только stat() будет делать секунд 10.
Пример работы Tup — инкрементная сборка Linux distro (похожая на Gentoo) gittup.org/gittup/
[marf@captainfalcon gittup]$ vi nethack/src/spell.c
[marf@captainfalcon gittup]$ vi busybox/coreutils/ls.c
[marf@captainfalcon gittup]$ time tup upd -j2
Executing Commands
[ 0/9 ] busybox/coreutils/CC ls.c
[ 1/9 ] nethack/CC src/spell.c
[ 2/9 ] busybox/coreutils/LD built-in.o
[ 3/9 ] busybox/LD busybox
[ 4/9 ] nethack/LD nethack
[ 5/9 ] initrd/bin/CP busybox
[ 6/9 ] initrd/bin/CP nethack
[ 7/9 ] initrd/MKINITRD
[ 8/9 ] initrd/GZIP initrd
[ 9/9 ]
real 0m1.571s
user 0m1.888s
sys 0m0.269s
Полторы секунды. Вот это я и подразумеваю быстрая инкрементрая сборка. gmake только stat() будет делать секунд 10.
> Пример работы Tup — инкрементная сборка Linux distro (похожая на Gentoo) gittup.org/gittup/
Всё-таки это довольно специфичная задача. И в любом случае это не 6 вложенных папок по 10 файлов, как в случае тестирование tup на 1000000 файлах.
> Полторы секунды. Вот это я и подразумеваю быстрая инкрементрая сборка. gmake только stat() будет делать секунд 10.
А tup не делает его как будто, и получает информацию об изменённых файлах астральным путём? ;) Что-то я сомневаюсь.
Попробую на досуге подкрепить свои слова аргументами.
Всё-таки это довольно специфичная задача. И в любом случае это не 6 вложенных папок по 10 файлов, как в случае тестирование tup на 1000000 файлах.
> Полторы секунды. Вот это я и подразумеваю быстрая инкрементрая сборка. gmake только stat() будет делать секунд 10.
А tup не делает его как будто, и получает информацию об изменённых файлах астральным путём? ;) Что-то я сомневаюсь.
Попробую на досуге подкрепить свои слова аргументами.
> А tup не делает его как будто, и получает информацию об изменённых файлах астральным путём? ;) Что-то я сомневаюсь.
Tup делает но только один лишь раз. Далее использует inotify. По ссылке все описано как это работает.
Tup делает но только один лишь раз. Далее использует inotify. По ссылке все описано как это работает.
Только если запустить демон `tup monitor`. При этом в описании теста gittup.org/tup/make_vs_tup.html не сказано, что перед вторым запуском запускался монитор. Это и вызывает сомнения, ибо в таком случае tup upd будет сканировать всё и вызывать stat-ы
В остальном же получается, что кроме удобного синтаксиса мы выигрываем только за счёт отсутствия stat-а и только при запущенном мониторе.
В остальном же получается, что кроме удобного синтаксиса мы выигрываем только за счёт отсутствия stat-а и только при запущенном мониторе.
Для полноты картины добавлю также Scons и Waf. Первый более развитый, второй более быстрый и архитектурно более правильный. Для написания кода в обоих используется Python, что не может не радовать.
bash стандартнее чем Python и Lua (Premake из соседнего коммента) когда-либо будут.
Скажите это сюда: habrahabr.ru/blogs/development/111691/#comment_3565108
И сюда: habrahabr.ru/blogs/development/111691/#comment_3565190
И сюда: habrahabr.ru/blogs/development/111691/#comment_3565190
Вы это _серьёзно_? Подскажете, где посмотреть _стандарт_ на _bash_?
ru.wikipedia.org/wiki/Де-факто
-_- Вы же не глупый человек, понимаете что _скрипты пишут на bash_, как это ни прискорбно. Вы ведь не будете предлагать использовать Lua или Python только для билд-скриптов. Tcl — хороший кандидат. И формальнй стандарт присутствует, и система компактная, и синтаксис умещается на страничку. Только вот нет на нём билд-систем.
-_- Вы же не глупый человек, понимаете что _скрипты пишут на bash_, как это ни прискорбно. Вы ведь не будете предлагать использовать Lua или Python только для билд-скриптов. Tcl — хороший кандидат. И формальнй стандарт присутствует, и система компактная, и синтаксис умещается на страничку. Только вот нет на нём билд-систем.
Вот даже в контексте разговора про системы сборки, я ни разу не вижу какого-либо доминирования bash (или даже sh, если вы имели в виду на самом деле его). Например, для тех, кто планирует быть портабельными под Windows, вероятность запуститься на Windows с cmake-системой или даже с какими-нибудь скриптами на python — радикально выше, чем если там что-то, написанное на bash, даже еще наверняка и с жестокой привязкой к какой-то определенной файловой иерархии, механизмам ldconfig и т.п.
Да, конечно sh. Все до единого известные мне портабельные проекты всё-равно собираются под mingw или MSYS. Ну и в конце концов ответьте:
> вероятность запуститься на Windows с cmake-системой или даже с какими-нибудь скриптами на python — радикально выше, чем если там что-то, написанное на bash
КАК ИСПОЛЬЗОВАТЬ cmake ДЛЯ ПРОЕКТОВ БЕЗ СИ И ПЛЮСОВ?!? Уже третий раз вижу предложение использовать cmake, а как собрать им, например код на D, так никто и не рассказал. Python неприемлем по причинам писанным выше.
> вероятность запуститься на Windows с cmake-системой или даже с какими-нибудь скриптами на python — радикально выше, чем если там что-то, написанное на bash
КАК ИСПОЛЬЗОВАТЬ cmake ДЛЯ ПРОЕКТОВ БЕЗ СИ И ПЛЮСОВ?!? Уже третий раз вижу предложение использовать cmake, а как собрать им, например код на D, так никто и не рассказал. Python неприемлем по причинам писанным выше.
Все до единого известные мне портабельные проекты всё-равно собираются под mingw или MSYS
Вы либо обладаете достаточно узким кругозором, либо, что скорее — хотели сказать что-то не то, что сказали. Например, масса проектов на Qt (хотя бы на том же qt-apps.org посмотрите — их не так мало) собираются с помощью qmake, которая не требует использовать никаких sh-скриптов, не требует никакого UNIX toolkit'а на собирающей машине и имеют возможность прекрасно собраться на Windows-машине с только Microsoft Visual Studio и их чудным C-компилятором.
КАК ИСПОЛЬЗОВАТЬ cmake ДЛЯ ПРОЕКТОВ БЕЗ СИ И ПЛЮСОВ?!? Уже третий раз вижу предложение использовать cmake, а как собрать им, например код на D, так никто и не рассказал.
Во-первых, пожалуйста, не кричите, во-вторых, сэкономьте мне немного времени и расскажите тогда уж сразу, чем именно вам не нравится CMakeD?
Нет, я обладаю узким кругозором. По счастливой случайности никогда не пробовал под виндовс собрать что-то, требующее большего чем mingw.
> чем именно вам не нравится CMakeD?
Спасибо, посмотрю, но D — тоже не единственный в мире язык. Вы продолжаете игнорировать мою главную мысль, высказанную в самом начале ветки. Все любимые вами утилиты требуют допиливания под *каждый* сценарий использования. make — нет.
> чем именно вам не нравится CMakeD?
Спасибо, посмотрю, но D — тоже не единственный в мире язык. Вы продолжаете игнорировать мою главную мысль, высказанную в самом начале ветки. Все любимые вами утилиты требуют допиливания под *каждый* сценарий использования. make — нет.
>Да, конечно sh. Все до единого известные мне портабельные проекты всё-равно собираются под mingw или MSYS
Притащить на Винду MinGW это совсем не то же самое, что притащить туда целый Cygwin.
Притащить на Винду MinGW это совсем не то же самое, что притащить туда целый Cygwin.
Про “скрипты пишут на bash” я бы поспорил. Во-первых, их много на чём пишут :) но это я не о том. Во-вторых, если уж говорить о стандартном unix-shell, то таковым является не bourne-again shell, а тот, который описан в IEEE Std 1003.2 (с ногами, растущими из korn shell). bash стал де-фактом по понятной причине — linux. Фактически навязан. Оно бы и не беда, если бы не одно “но” — количество людей, уверенных, что sh == bash огромно (благодаря тому, что в linux'ах он таки называется /bin/sh). Когда бы все они были просто юзерами, то не было бы проблемы — пусть каждый пользует то, что ему нравится. Но когда на нём начинают писать портабельные (якобы) скрипты, вот здесь веселье и начинается. Я уже не возьмусь сосчитать, сколько раз приходилось объяснять людям, почему у них не работают массивы :)
Люто ненавижу Makefile с bash'евскими конструкциями.
Люто ненавижу Makefile с bash'евскими конструкциями.
В Linux'ах всё на самом деле по-разному. В том же Debian/Ubuntu, например, /bin/sh — это dash.
Проблема даже не в башизмах так таковых, а более общая — в том, что сам стандарт и на POSIX shell, и на *utils — объективно плохой или, как минимум, устаревший. Как следствие — мы имеем несколько тысяч реализаций, в которых «shell is 98% POSIX compatible», а в utils нескольких утилиток нет, а еще несколько — работают с определенными отклонениями (в лучшую сторону, конечно же, по мнению автора) от стандарта.
Субъективно — на сейчас — UNIX shell — один из самых непортабельных языков вообще. Ситуация с ним напоминает ситуацию с языком C до середины 90-х годов, но с C ее хоть как-то порешали (хотя и тоже плохо и сумбурно), а за UNIX shell, видимо, не стоят такие гиганты индустрии…
Проблема даже не в башизмах так таковых, а более общая — в том, что сам стандарт и на POSIX shell, и на *utils — объективно плохой или, как минимум, устаревший. Как следствие — мы имеем несколько тысяч реализаций, в которых «shell is 98% POSIX compatible», а в utils нескольких утилиток нет, а еще несколько — работают с определенными отклонениями (в лучшую сторону, конечно же, по мнению автора) от стандарта.
Субъективно — на сейчас — UNIX shell — один из самых непортабельных языков вообще. Ситуация с ним напоминает ситуацию с языком C до середины 90-х годов, но с C ее хоть как-то порешали (хотя и тоже плохо и сумбурно), а за UNIX shell, видимо, не стоят такие гиганты индустрии…
Вспомнилась фраза «It's easier to port a shell than a shell script. — Larry Wall»
Спасибо! Побольше бы подобных статей!
www.gnu.org/software/make/manual/html_node/Implicit-Variables.html — иначе получается, что компилировать C++ мы можем только командой g++, C — почему-то тоже этой же командой, а файлы удалять — только rm.
Я для подсветки использовал этот сайт. Надо только не забыть поставить галочку «Use tag (for Habrahabr)» и «Line number», а в результирующем коде внутрь тега blockquote поставить тег code.
Единственный минус — там нет подсветки для Make, но можно использовать либо «Bash», либо «Plain text».
Единственный минус — там нет подсветки для Make, но можно использовать либо «Bash», либо «Plain text».
Забыл самое главное — полный список доступных «оформителей» доступен в этом посте
Зачем, если на хабре есть <source />?
я бы еще добавил в этот makefile код, который бы учитывал библиотеки как с ключом L, так и с ключом l.
И все таки в один clean объединять все rm'ы, ИМХО это как-то неправильно.
У вас нумерация списка в статье какая-то непоследовательная :)
Спасибо, я лучше SCons возьму.
Извините, но это плохой, негодный мейкфайл.
make --directory=./obj/Release --makefile=../../Makefile build_flags="-O2 -fomit-frame-pointer" program_name=../../bin/applicationТаки вам не кажется, что это очень грязный хак?
У вас всё сломается если вдруг в одной директории обнаружатся два файла dummy.c и dummy.cpp
А ещё встречаются расширения .cxx .cc .hxx .hh .hpp
Кстати, иногда приходится собирать за раз несколько бинарников с разными клюджами -DWITH_abc
И чтоб один скрипт сборки понимал что под ним линукс или винда или вообще эмулятор встраиваемой платформы.
Но это всё поправимо при желании, просто каждый затачивает систему сборки под свой проект сам. И это, не люблю почему-то VPATH, непомню конкретно, но что-то там криво было у make с ним, может сейчас прошло уже…
А вот autotools и прочие свистелки годятся только для проектов на sf.org, т.е. там, где люди сами толком не знают какие библиотеки у них в системе стоят и вообще, как у них там всё работает.
Когда грамотный человек что-то разрабатывает, то он будет сам контролировать какая библиотека у него подцепилась и какой инклюд откуда сработал. Я не буду разбираться кто виноват, я или этот autotools — просто исключу его из цепочки и спокойно буду работать.
autotools можно будет добавить позже, но в работе он только мешает
А ещё встречаются расширения .cxx .cc .hxx .hh .hpp
Кстати, иногда приходится собирать за раз несколько бинарников с разными клюджами -DWITH_abc
И чтоб один скрипт сборки понимал что под ним линукс или винда или вообще эмулятор встраиваемой платформы.
Но это всё поправимо при желании, просто каждый затачивает систему сборки под свой проект сам. И это, не люблю почему-то VPATH, непомню конкретно, но что-то там криво было у make с ним, может сейчас прошло уже…
А вот autotools и прочие свистелки годятся только для проектов на sf.org, т.е. там, где люди сами толком не знают какие библиотеки у них в системе стоят и вообще, как у них там всё работает.
Когда грамотный человек что-то разрабатывает, то он будет сам контролировать какая библиотека у него подцепилась и какой инклюд откуда сработал. Я не буду разбираться кто виноват, я или этот autotools — просто исключу его из цепочки и спокойно буду работать.
autotools можно будет добавить позже, но в работе он только мешает
Что-то тут нечисто. Попробуйте мой.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пример Makefile