А где можно посмотреть примеры грамотоно составленных Makefile'ов для больших проектов?

/usr/src/linux ?

Так там, вроде, несложная структура проекта. У меня просто несколько либ, сделанных разными людьми, они должны собираться отдельно, в то же время они должны быть в зависимостях.

Для больших проектов не надо Makefile ручками делать. Есть как минимум автотулзы. Или всякие их заменители.

>А где можно посмотреть примеры грамотоно составленных Makefile'ов для больших проектов?
Нигде, грамотные люди используют cmake.

> Нигде, грамотные люди используют cmake.
Не всегда.
Например http://www.zeroc.com/ice.html пишут Makefile'ы сами, без autotools или cmake.

> А то по мере усложнения проекта мой Makefile стал совсем ужасным.

У тебя один Makefile на большой проект? O_o

как уже тут выше говорили, autotools тебе в руки.

вот мой случай..

fantom@halturin:~/devel/Projects/gsql$ find -name \*.[ch] | wc -l
205
fantom@halturin:~/devel/Projects/gsql$ find -name Makefile.am | wc -l
20

если конечно задаться целью, то можно и без автотулзов. но при постоянном развитии проекта просто лопнеш/опухнешь/умрешь все это поддерживать.

да, совсем забыл... есть еще http://www.scons.org/. На них КДЕ одно время собирался перелазить, но что-то не срослось и они оставили эту затею. как-то так. глянь, может тебе подойдет.

>У тебя один Makefile на большой проект? O_o

Пришел и все опошлил. Нет конечно.

Да, есть же scons, вспомнил. Вроде больше подходит. С autotools связываться не хочу. Спасибо.

Вот примерный сценарий для автотулз :

Создадим новый каталог для проекта kalkulc. 
Внутри него создадим вложенный каталог src, и перенесём в каталог src все три файла от C-версии 
нашего калькулятора. Это main.c, calculate.c, calculate.h. 

Вставьте в самое начало каждого из этих трёх файлов (main.c, calculate.c и calculate.h) макрос, 
требующий включения файла config.h.
	#ifdef HAVE_CONFIG_H
	#include 
	#endif

В каталоге проекта создадим файл configure.ac со следующим текстом.
	AC_INIT(src/main.c)
	AM_CONFIG_HEADER(src/config.h)
	AM_INIT_AUTOMAKE(kalkul,0.1)
	AC_PROG_CC
	AC_PROG_CXX
	AC_PROG_INSTALL
	AC_OUTPUT(Makefile src/Makefile)

Здесь же создаём файл Makefile.am с одной строчкой.
	SUBDIRS = src

А внутри каталога src – ещё один Makefile.am.
	bin_PROGRAMS = kalkul
	kalkul_SOURCES = calculate.h calculate.c main.c
	kalkul_LDADD = -lm

Строчка kalkul_LDADD = -lm указывает, какую библиотеку следует подключить при компиляции.

Далее в командной строке набираем команды :
	aclocal
	autoconf
	touch NEWS README AUTHORS ChangeLog
	autoheader
	automake -a
	./configure
	make
	make dist

Ужас как много! Хорошо, что есть ant/nant/msbuild, где все запускается одной командой...

На самом деле таким мнением обладают люди не вникшие во всю прелесть автотулза. Он весьма гибок. Да, проседает по производительности, но так или иначе, для больших проектов, с кучей разных ветвлений для линковки и сборки имхо самое оно.

scons не пользовался, но по-диагонали знакомился с ним. в принципе хорош, но для больших проектов, мне кажется, еще слабоват.

>да, совсем забыл... есть еще http://www.scons.org/. На них КДЕ одно время собирался перелазить, но что-то не срослось и они оставили эту затею. как-то так. глянь, может тебе подойдет.

Читал про кде. Там группа фанатов scons пару месяцев пыталась собрать под ним kdelibs и з***алась. А потом то же самое сделали за месяц для cmake. + к тому разрабы cmake выявили свою заинтересованность в практическом применении cmake для такого большого проекта и предложили при необходимости дорабатывать cmake под их нужды. З.Ы. перелезали они как раз с autotools, который их поддостал.

> Ужас как много! Хорошо, что есть ant/nant/msbuild, где все запускается одной командой...

главное джаву в дистрибутив проекта не забыть запихнуть, а то без неё ant ничего не соберёт :)

Годный мануал, спасибо!!!!

blender и chromium вроде не маленькие

Нужно знать много деталей, а это не есть хорошо. Судя по описанию kto-tama - высокий порог вхождения. Вообще, считаю, что разброд и шатание в мире билдеров плюсовых программ не совсем хорошее явление. Слишком большой выбор утомляет.

Да, и мейкфайлы довольно таки низкоуровневые, чтобы для большого проекта писать их вручную. Хотя именно с такими написанными вручную мне приходилось иметь дело. Правда, последний проект был где-то на мегабайт, то есть, не такой большой. Собирался всего один бинарник. Но было до черта флагов (есть один странный любитель плодить #ifdef в коде на каждый чих). Поэтому Makefile был немаленький. Скорее всего, автоматизации задача не подлежала. Мне совершенно не понравилось.

CMake по сравнению с autotools
1. простой по написанию
2. одна команда cmake вместо всей компании autoconf automake ... ./configure
3. Показывает прогресс сборки.
4. Имеет встроенные скрипты для определения и подключения большинства широко используемых библиотек.
5. Автоматом определяет изменения в системе сборки и самостоятельно и быстро переконфигурируется (не надо снова запускать всю ересь из autotools)
6. Позволяет генерировать не только make-файлы, но и проекты для сред разработки.

+1

Аналогичный пример от kto_tama, но на cmake будет задаваться 3мя строками.

>> Аналогичный пример от kto_tama, но на cmake будет задаваться 3мя строками.

код - в студию !

project(calc)
add_executable(calc calculate.h calculate.c main.c)
target_link_libraries(calc m)

Вот примерный сценарий для cmake:

Создадим новый каталог для проекта kalkulc.
перенесём в каталог все три файла от C-версии
нашего калькулятора. Это main.c, calculate.c, calculate.h.

CMakeLists.txt (писал по памяти, если что не бейте сильно!):

include_directory(.)
add_executable(kalkulc main.c calculate.c)
target_link_libraries(kalkulc, m)



Далее в консоли:
cd project_dir
mkdir build && cd build
cmake ..
make
sudo make install

Опередил:)

1. Разве без project не соберется?
2. Хедеры надо в executable добавлять?

причем это работать будет везде, а не только в unix-like

target_link_libraries(kalkulc, m)
следует читать как target_link_libraries(kalkulc m)

Не обязательно, но если хочешь, чтоб они у тебя появились в дереве проекта в студии, то лучше добавить.

Спс.
А include_directories(.) идет автоматом? Я всегда прописывал..

Если у тебя структура такая:
project/src/
project/src/source1.c
project/src/source2.c
project/src/include1.h

и сборка идет внутри src, то include_directories(.) не нужна, если сборка идет в project/ (исходники добавлены с префиксом src/), то include_directories(.) нужна.

Еще если свои инклудники включаешь треугольными скобками, то . тоже понадобится.

Сори. Забыл про этот момент. Конкретно про то, что "" - это поиск в текущем каталоге. Мне уже лечиться пора.

текущий проект

$ find . -name \*.[ch] -or -name \*.cpp | wc -l
1964

$ find . -name CMakeLists.txt | wc -l
16

$ find . -name CMakeLists.txt | xargs cat | wc -l
767

Я недавно извернулся и сделал в CMakeLists автоматический поиск и добавление всех *.cpp из подкаталогов в проект.

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

> Я недавно извернулся и сделал в CMakeLists автоматический поиск и добавление всех *.cpp из подкаталогов в проект.

Можно посмотреть?

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

Не самая большая проблема.

Вопрос всем: как с cmake под macosx?

> Да, есть же scons, вспомнил. Вроде больше подходит.

Scons более-менее делает своё дело, но тормознут. Это становится хорошо заметно когда проект вырастает, а пересобирать его приходится часто. При каждой пересборке scons подключает все файлы сборки подпроектов и вычисляет весь процесс целиком прежде чем начать хоть что-то делать. Разумеется, на это уходит куча времени (тем более, что это питон). Это то, с чем я сталкивался в версиях 0.9*. Может что-то и поменялось, но сомнительно. Для себя сделал вывод, что если подход autotools, cmake и т.п. (генерация промежуточных make-файлов) не так красив, то, по крайней мере, он оправдан.

>Годный мануал, спасибо!!!!
тема autoscan не раскрыта

>Я недавно извернулся и сделал в CMakeLists автоматический поиск и >добавление всех *.cpp из подкаталогов в проект.

У меня все файлы раскиданы по библиотекам, а добавляются в проект по наличию CMakeLists.txt в корне.

macro(GA_ADD_SUBPROJECTS)
file(GLOB paths RELATIVE "${CMAKE_CURRENT_SOURCE_DIR}" "*/CMakeLists.txt")
MESSAGE(STATUS "Subprojects:")
foreach(cur_path ${paths})
get_filename_component(lib_dir ${cur_path} PATH)
MESSAGE(STATUS "+ " ${lib_dir})
add_subdirectory(${lib_dir})
endforeach(cur_path paths)
endmacro(GA_ADD_SUBPROJECTS)

Но этот макрос взят из boost. Может есть способ и проще, но меня и этот устраивает.

>> Я недавно извернулся и сделал в CMakeLists автоматический поиск и добавление всех *.cpp из подкаталогов в проект.

>Можно посмотреть?


execute_process(COMMAND find ${CMAKE_CURRENT_SOURCE_DIR} -type d OUTPUT_VARIABLE ALL_DIRS)

string(REGEX REPLACE "${CMAKE_CURRENT_SOURCE_DIR}/" "" ALL_DIRS ${ALL_DIRS})
string(REGEX REPLACE "\r" "" ALL_DIRS ${ALL_DIRS})
string(REGEX REPLACE "\n" ";" ALL_DIRS ${ALL_DIRS})

include_directories(${ALL_DIRS})

foreach(DIR ${ALL_DIRS})
set(DIR_SRCS "")
aux_source_directory(${DIR} DIR_SRCS)
set(ALL_SRCS ${ALL_SRCS} ${DIR_SRCS})
endforeach(DIR)

лучше делать так: Отдельный каталог - отдельный подпроект. Подпроект это либа(ы) либо бинарник(и), в каждом каталоге по отдельному CMakeLists.txt.


Включение всего делается очень просто:
file(GLOB SRC *.c *.cpp *.h)
add_library(name ${SRC})

Ну ведь иногда один подпроект необходимо разделить на каталоги для простоты понимания и чтобы избежать свалки. Тогда мой подход оправдан.

Посмотрел в мане есть еще GLOB_RECURSE, который делает рекурсивный обход. Получается, что твой некроссплатформенный вариант с find'ом вообще не нужен.

Хм... Увидел GLOB_RECURSE. Да, с ним будет проще сделать чем так как я делал.

Во-во. Я недавно с cmake:)

>Включение всего делается очень просто

А чем не нравится

aux_source_directory(. DIR_SRCS)
add_library(name ${DIR_SRCS})

?

Мне показалось её действие неочевидным. Указать расширения для файлов мне кажется как-то надежнее :)

Ещё у CMake есть офигенно приятные (когда работают) CTest и CDash. У нас в проекте работают... Что самое приятное в этом, заморочек с добавлением поддержки ctest и cdash в проект был минимум. Основная трудность была выяснить, как это всё делается.

ctest использую, cdash нет, так как не осилил в чем его смысл

Когда много тестов, много ежедневных сборок на разных тачках с разными настройками, плюс coverage, плюс valgrind, то весьма удобно собирать и отображать данные в CDash.

> Мне показалось её действие неочевидным. Указать расширения для файлов мне кажется как-то надежнее :)

aux_source_directory - не обрабатывает хидера (он использует неконцигурируемую переменную в которой хранятся типовые разширения для языка, а хидеров в ней нету). в принципе для билда из консоли нормально, но для IDE-ок - лучше исползовать glob *.cpp *.hpp