LINUX.ORG.RU

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


0

1

Вот сделал систему сборки на основе GNU make. Прошу желающих потестить. Установка: 1) Клонируем git@github.com:vsemyonoff/umake.git; 2) Копируем Makefile и папку .umake в каталог проекта (или просто делаем симлинк на Makefile); 3) первый раз make генерирует файл настроек; 4) правим наш_проект.prj; 5) опять make для сборки. Вобщем подробнее в ридми (ангийский хромает, но русские поймут :-) ). ЗЫ: да велосипед, но надо же make освоить.


Ответ на: комментарий от Eddy_Em

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

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

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

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

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

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

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

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

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

...
aux_source_directory(. SOURCES)
...
cuda_add_executable(${PROJ} ${SOURCES} ${CUFILE} ${PO_FILE} ${MO_FILE} ui.h)
...
и нужные обработчики подключаются...

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от CEMEH

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

	find_package(CUDA)
	if(CUDA_FOUND)
		add_definitions(-DCUDA_FOUND)
	endif(CUDA_FOUND)
находит даже в нестандартных директориях.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну а вообще, 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? В общем, для меня ценность этой фичи в системе сборки очень сомнительна.

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поэтому логично, что нормальные системы сборки пошли чуть далее чем 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 тоже умеет

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

> cmake тоже умеет

cmake тоже умеет


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

:3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

да

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

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

CEMEH
() автор топика

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

CEMEH
() автор топика
Ответ на: комментарий от Reset
an@nymous:~/CMakeTest/build$ find ..
..
../source
../source/CMakeLists.txt
../source/src
../source/src/prog.cpp
../build
an@nymous:~/CMakeTest/build$ cat ../source/CMakeLists.txt 
project(prog)
add_executable(prog src/prog.cpp)
an@nymous:~/CMakeTest/build$ cmake ../source/
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/anonymous/CMakeTest/build
an@nymous:~/CMakeTest/build$ make
Scanning dependencies of target prog
[100%] Building CXX object CMakeFiles/prog.dir/src/prog.cpp.o
Linking CXX executable prog
[100%] Built target prog
an@nymous:~/CMakeTest/build$ ./prog 
an@nymous:~/CMakeTest/build$ cd ../..
an@nymous:~$ mv CMakeTest/ CMakeTest1/
an@nymous:~$ cd CMakeTest1/build/
an@nymous:~/CMakeTest1/build$ make
CMake Error: The source directory "/home/anonymous/CMakeTest/source" does not exist.
Specify --help for usage, or press the help button on the CMake GUI.
make: *** [cmake_check_build_system] Error 1
an@nymous:~/CMakeTest1/build$ cmake ../source/
CMake Error: The current CMakeCache.txt directory /home/anonymous/CMakeTest1/build/CMakeCache.txt is different than the directory /home/anonymous/CMakeTest/build where CMackeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt
CMake Error: The source "/home/anonymous/CMakeTest1/source/CMakeLists.txt" does not match the source "/home/anonymous/CMakeTest/source/CMakeLists.txt" used to generate cache.  Re-run cmake with a different source directory.

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