Автоматическая сборка с GNU Make

Здесь Reset советовал мне осваивать cmake. Попробовал - отличная вещь. Советую и вам освоить.

Я знаю, но если не нужна кроссплатформенная сборка - это лишняя сущность (ИМХО)

А оно и без кроссплатформенности удобно, особенно если у вашего проекта 100500 зависимостей.

CMake гораздо лучше ввсех известных мне аналогов на любом мало-мальски сложном проекте

Велосипеды.

ТС срочно пройти курс CMake

Согласен.

FindXXXXX божественны.

На слочай зависимостей есть pkg-config, он тоже поддерживается данной системой. Зависимости между целями в одном проекте тоже резолвит. А основное отличие от cmake в том, что избавляет от кучи писанины. Можно указать каталог с исходниками и по расширению файлов подключатся нужные обработчики (пока что только 'c' и 'cpp').

> ТС срочно пройти курс CMake

Я его давно прошел и, не поверите, даже использовал. А велосипед сделал для случаев, когда нужно быстро собрать студийный проект на «посмотреть» например. Идея такая: есть куча исходников нужно их собрать без прописывания каких-то строчек по каждому файлу и т.п.

> Велосипеды.

Вау... Глубочайшая мысль...

> FindXXXXX божественны

Это к чему?

Так cmake так умеет:

...
aux_source_directory(. SOURCES)
...
cuda_add_executable(${PROJ} ${SOURCES} ${CUFILE} ${PO_FILE} ${MO_FILE} ui.h)
...

Например, к этому:

	find_package(CUDA)
	if(CUDA_FOUND)
		add_definitions(-DCUDA_FOUND)
	endif(CUDA_FOUND)

Я очень рад. Тоже самое я сейчас имею и без cmake. Господа! Я не просил оценить нужность данного «велосипеда», а попросил желающих протестить новую версию. Этот «велосипед» был изготовлен в 2009 году и успешно использован мною в нескольких коммерческих проектах. Баги частично фиксились по ходу использования. Теперь дошли руки переписать и дописать нужные фичи, а времени на тестирование не хватает - отсюда и начался данный топик. ЛОР в своем репертуаре. По существу, пока, ни одного ответа. Жаль.

Теперь дошли руки переписать и дописать нужные фичи, а времени на тестирование не хватает - отсюда и начался данный топик

Ну так не ясен смысл использования этого велосипеда вместо cmake. Или же вы предлагаете тратить время на ненужные вещи?

Уж лучше waf

Уже писал. Я для себя обеспечил средсвами make возможность автоматической сборки, тот минимум, который мне необходим. Cmake в данном случае не нужен. Файл конфигурации, который генерится в моем случае легок для понимания, и не требует долгого курения мануалов и т.п. Пример: недавно отправил заказчику исходник (2 конфига - debug release), он мне пишет, что за 15 мин добавил еще 2 - x86(debug, release) и x86_64(debug, release). А если бы был cmake? ЗЫ: я никого не агитирую использовать что либо, просто я знаю: если данный велосипед нужен мне, то наверняка есть люди, которым это тоже нужно или просто интересно. Возможно на ЛОРе есть таковые? Вот им и был адресован данный топик.

в pkg-config прописываются далеко не все библиотеки.

Можно указать каталог с исходниками и по расширению файлов подключатся нужные обработчики

В cmake для этого file(GLOB ...) имеется. Но вообще автоматическое добавление исходников в сборку это зло.

А если бы был cmake?

В cmake есть профили сборки. Хоть десяток создай.

Оно умеет генерить файлы проектов для родных сред? Сколько библиотек оно умеет находить из коробки? И чем собственно оно лучше?

Но вообще автоматическое добавление исходников в сборку это зло.

А мне нравится: не нужно изменять содержимое cmakelist.txt каждый раз при добавлении в проект новых файлов.

> вообще автоматическое добавление исходников в сборку это зло.

А зачем тогда вообще нужны автоматические системы сборки?

> В cmake есть профили сборки. Хоть десяток создай.

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

Оно умеет генерить файлы проектов для родных сред?

Читайте внимательно топик: ==>автоматическая сборка с GNU Make<==. В данном случае родная среда это: vim/emacs + gcc + make. Если смотреть с этой точки зрения - да умеет :-). По существу это универсальный makefile.

Сколько библиотек оно умеет находить из коробки?

Все что умеет pkg-config

И чем собственно оно лучше?

Лучше чего? Я где-то написал, что что-то лучше чего-то? Сравнивать с cmake? Это разные инструменты. Разные цели. Вы черпаком чай размешивать станете? Нет? Вот и я не хочу возиться с cmake, если мне не нужны «файлы проектов для родных сред». Что искать? Я прописал все либы поддерживаемые pkg-config в файл проека, а что нет - в requirements проекта и все. Городить огород скриптов поиска считаю дурацким занятием. Все что мне нужно указать при сборке проекта: имя цели, флаги препроцессора, компилятора, линкера и, по возможности, зависимости(внешние и внутренние). Этого я добился и решил поделиться с сообществом. Судя по всему, Вы не удосужились заглянуть в реп на гитхабе, а просто решили подискутировать...

Список файлов для сборки во всех крупных проектах делается руками. Сделано это для того, чтобы случайно в сборку не попали левые файлы, которые могут оказаться в директории в результате экспериментов.

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

Какого нахер недельного курения? Я когда cmake только стал использовать (кстати в 2007м году, когда на лоре о нем мало кто знал), то сразу же нашел как делаются и меняются профили.

По существу это универсальный makefile.

cmake более универсальный

Я прописал все либы поддерживаемые pkg-config в файл проека, а что нет - в requirements проекта и все.

ага, а потом с бубном плясать, если вдруг в твоей системе библиотека лежит не там, где ты предполагал. Нафиг нафиг!

> Какого нахер недельного курения? Я когда cmake только стал использовать (кстати в 2007м году, когда на лоре о нем мало кто знал), то сразу же нашел как делаются и меняются профили

Человек, не знакомый с cmake, должен сначала разобраться с cmake, а начать потом делать и менять профили.

cmake более универсальный

При чем тут вообще cmake? Вы фанат cmake(один их первых на лоре!!!)? На здоровье! Но топик не о cmake. Организуйте в talks тему и нахваливайте его там.

И чем собственно оно лучше?

гы, названием

Ну а вообще, recursive make considered harmful — У Make множество проблем: это ненадёжные инкрементальные сборки, ненадёжные зависимости на сгенерированные файлы, медленная рекурсивная сборка из-за двухпроходности интерпретатора, слишком подробный и детальный язык сборки, из-за чего чтобы написать что-то практически полезное нужны уже генераторы вроде autotools или cmake (или извращаться с набором универсальных Makefile, как в FreBSD, более-менее прямо в Google Go, или вот как топикстартер).

Поэтому логично, что нормальные системы сборки пошли чуть далее чем GNU Make, искореняя его детские болезни и будучи более высокоуровневыми: Perforce Jam/kjam/Boost.Jam на DSL, ANT/NANT/MSBUILD на XML, Make++ на перле, cons на перле в Quake/SCons на питоне/Waf на питоне

плюс, их принципиально проще расширять

см. доку wafbook

Сколько библиотек оно умеет находить из коробки?

см. wafbook pkgconfig есть, 9.4.4. apidocs

из коробки умеет много языков: C/C++, D, Vala, Lua, Fortran :) , Java, C#

умеет юниттесты

Оно умеет генерить файлы проектов для родных сред?

насколько я понял, нет (если не прав, поправьте), но такая фича в общем-то нужна только для визуал студио, а тут msvc поддерживается из коробки — в нормальных системах нормально работает и GNU Make, а в винде оно тормозит из-за кривой реализации пайпов через временные файлы. Какие среды тут нужны? Visual Studio/XCode/Eclipse? В общем, для меня ценность этой фичи в системе сборки очень сомнительна.

> Список файлов для сборки во всех крупных проектах делается руками.
если они всё равно хранятся в какой-то VCS, можно ведь получить список файлов, которые НЕ находятся под version control, и их не включать.

Сделано это для того, чтобы случайно в сборку не попали левые файлы, которые могут оказаться в директории в результате экспериментов

если файлы левые экспериментальные, но Makefile написан в общем, универсальном виде, по правилам, то да, могут быть проблемы. Но это проблемы GNU Make, который не позволяет более точно описать сборку (например, по зависимостям автоматически определить что эти файлы идут в другой отдельный бинарник). Нормальные системы сборки умеют сканировать зависимости на включаемые файлы и в целом более надёжно определяют, когда нужно выполнять пересборку.

Кстати, а твоё поделие автоматические зависимости по инклудам распознаёт? Как, через gcc -D? Насколько сложно прикрутить в .umake/handlers другие языки, вроде Vala, Lua, D, tex? В том же waf есть встроенный сканер под эти языки.

Кстати, а твоё поделие автоматические зависимости по инклудам распознаёт?

Файлы зависимостей для C/C++ генерит автоматом ($(CXX) -M xxx.cpp).

Как, через gcc -D?

Это как? -Dxxx вроде бы определяет макрос xxx?

Насколько сложно прикрутить в .umake/handlers другие языки, вроде Vala, Lua, D, tex?

Каждый handler выбирает из списка SOURCESLIST свой тип файлов и обрабатывает их как хочет. Т.е. если на выходе хендлера объектники - он их добавит в зависимоти линкера, если маны - просто сгенерирует и все. Хендлер определяется по расширению файла и инклюдится автоматом (если он вообще есть). В старой версии была поддержка asm (yasm, т.к. умеет генерить список пререквизитов), за ненадобностью не стал добавлять (пока). Вобщем не сложно.

тьфу, gcc -M

Человек, не знакомый с cmake, должен сначала разобраться с cmake, а начать потом делать и менять профили.

Это недолго. Посмотрите по ссылке в самом первом моем сообщении в этой теме, сколько времени у меня ушло на то, чтобы разобраться с cmake.

Оно умеет генерить файлы проектов для родных сред? Сколько библиотек оно умеет находить из коробки? И чем собственно оно лучше?

Сори, не заметил кому комент адресован.

Поэтому логично, что нормальные системы сборки пошли чуть далее чем GNU Make, искореняя его детские болезни и будучи более высокоуровневыми: Perforce Jam/kjam/Boost.Jam на DSL, ANT/NANT/MSBUILD на XML, Make++ на перле, cons на перле в Quake/SCons на питоне/Waf на питоне

Это всё не работает с родными средами, что усложняет разработку.

из коробки умеет много языков: C/C++, D, Vala, Lua, Fortran :) , Java, C#

cmake тоже умеет

умеет юниттесты

cmake тоже умеет

> cmake тоже умеет

cmake тоже умеет

cmake не умеет переносить смену каталога с исходниками и/или объектниками.

:3

Это недолго. Посмотрите по ссылке в самом первом моем сообщении в этой теме, сколько времени у меня ушло на то, чтобы разобраться с cmake.

Но это сделать все равно надо. Но если человеку это не интересно, он этим заниматься не станет. См. пример выше. Он работает на FreeBSD (например), знает опции компилятора в совершенстве и хочет что-то изменить в сборочном процессе. Ему легче будут поправить файл, в котором хранятся пары «переменная = значение», чем курить 3-х этажные маты cmake.

Я нисколько не умаляю значение cmake вцелом. Это просто круть, что есть такая полезная (+ еще много хорошего) тулзень, но любой инструмент нужно использовать там, где он приносит больше пользы, чем гемора.

Задумка была в том, чтобы избавиться от этой сборочной рутины, которой я ненавижу заниматься. Сделать раз и забыть.

Так оно у вас даже зависимости автоматом определяет и библиотеки прописывает? В смысле, запустил скрипт в директории с исходниками - получил готовый makefile без лишних заморочек. Так, что ли?

Это не скрипт. Это уже makefile. А файл(ы) конфига(ов), который(е) он генерит при первом запуске make - это просто инклюд(ы) который(е) потом этот makefile подключает.

Прочтите ридми, хотябы, на github'е

Так оно у вас даже зависимости автоматом определяет и библиотеки прописывает?

да

В смысле, запустил скрипт в директории с исходниками - получил готовый makefile без лишних заморочек. Так, что ли?

Нет. Запустил make [targetname.prj ...] - сгенерился шаблон для цели «targetname» или, по-умолчанию, имя текущего каталога. Отредактировал шаблон. Запустил make и получил бинарник. Если целей несколько - соберет все, если не указана конкретная. Если цель1 зависит о цели2 - echo «target1: target2» >> depends.prj - сборка произойдет в нужном порядке.

Не тот урл для клонирования дал :-)
git://github.com/vsemyonoff/umake.git

cmake не умеет переносить смену каталога с исходниками и/или объектниками.

чего?

Ну и?

Ну и вот.

это не баг, а фича

Все так говорят..

Не нужно. Осильте cmake и не пишите больше велосипедной херни.

Забыл у Вас спросить: нужно мне это или нет?