Третья статья о процессе компиляции

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

Да какой там туториал, вода одна. Ничего толком не написано... Типа, "я спохватился, но писать лень, но надо".

Не завидую я "чайнику", решившему освоить мейк при помощи этой статьи! Скопипастит он примеры, и ждет его мощный сурпрыз...

люди возненавидят make.

а вот если пользоваться следующим макефайлом - то можно:
1) бросать новое файло и не лезть в файл (зависимости автоматически генерируются)
2) копировать один и тот-же макефайл из проекта в проект, только меняя имя проги
3) компилить везде включая под цигвином
4) иметь main в файлах как юнит-тесты и включать - выключать нужный

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

--------8<----------
SHELL=/bin/sh

BIN=test

ARCH := `uname`

NOCYGWIN=

ifeq ($(ARCH), CYGWIN32/95)
NOCYGWIN= -mno-cygwin
endif
ifeq ($(ARCH), CYGWIN32/NT)
NOCYGWIN= -mno-cygwin
endif


#consider all *.c as sources
SOURCES.c := $(wildcard *.c)


CFLAGS= $(NOCYGWIN) -ansi -W -Wall
CPPFLAGS=
CC=gcc
SLIBS=
INCLUDES=
OBJS=$(SOURCES.c:.c=.o)
LINK=gcc $(CFLAGS)
LFLAGS=-lm $()

debug : CFLAGS = $(NOCYGWIN) -ansi -W -Wall -g -Wundef
pedantic : CFLAGS = $(NOCYGWIN) -ansi -W -Wall -g -Wundef -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
release : CFLAGS = $(NOCYGWIN) -ansi -W -Wall -O2
ut : CFLAGS = $(NOCYGWIN) -ansi -g -DUNIT_TEST -DHASH_UNIT_TEST

.SUFFIXES:
.SUFFIXES: .d .o .h .c
.c.o: ; $(CC) $(INCLUDES) $(CFLAGS) -MMD -c $*.c

.PHONY: clean

%.d: %.c
@set -e; rm -f $@; \
$(CC) -M $(CFLAGS) $< > $@.$$$$; \
sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < $@.$$$$ > $@; \
rm -f $@.$$$$

all release debug pedantic ut: $(BIN)

$(BIN): $(OBJS)
$(LINK) $(FLAGS) -o $(BIN) $(OBJS) $(LFLAGS)
clean:
-rm -f $(BIN) $(OBJS) *.d

include $(sources:.c=.d)

--------8<----------

через неделю он выучит automake и поделится с нами и этим сокровенным знанием. Потом дойдут руки до autoconf и понеслась по всем autotools. ;) В общем, аффтар пеши исчо

хе, через пару дней будет, ой я забыл про ./configure, надо написать

этим фекалом (make) кто-то ещё пользуется? да выучите же jam наконец!

>automake
>autotools

для многих маленьких проектов - где несколько файлов и почти нет внешних зависимостей (драйверов, например) - automake/autotools - overkill.
академия - ещё один пример (не пугайте студиозов м4 - им бы в простом make разобраться)

хотя вон говорят - jam'ы какие-то есть сегодня...

> нельзя рассказывать о разработке ПО и не (у)помянуть make.

там "у" лишняя. :)

make - такой же атавизм, как и текстовые потоки между ls и grep :) Процесс разработки стал настолько сложен, что тупой проверки дат и вызова генерации цели недостаточно. Тем не менее, возможно что все 100% линуксовых поделий компилятся именно мэйком. смишно...

А ведь Вирт давно уже предлагал создавать модульные системы! Там зависимости тоже есть, но куда слабже, чем линуксовые крюки.

> make - такой же атавизм, как и текстовые потоки между ls и grep :)

Зеленое громоздкое чешуйчатое быдло :)

> Процесс разработки стал настолько сложен, что тупой проверки дат и вызова генерации цели недостаточно.

Расскажи, что нужно такого, что не обеспечивается средствами make и его надстроек вроде cmake и autotools.

> Тем не менее, возможно что все 100% линуксовых поделий компилятся именно мэйком. смишно...

То есть у всех все работает, и только ты ходишь вокруг и ноешь? :)

Вообще, make хорошая утилита для всего, кроме компиляции.

Для компиляции нужен gprbuild.

> make - такой же атавизм, как и текстовые потоки между ls и grep :) Процесс разработки стал настолько сложен, что тупой проверки дат и вызова генерации цели недостаточно.

Тоньше.

> Тем не менее, возможно что все 100% линуксовых поделий компилятся именно мэйком. смишно...

Взошло солнце и ты превратился в камень :)

Ботва. Про компиляцию нада книжко читать в стиле "Основные концепции компиляторов" Хентера, а не статьи на 10 абзацев.

Хантера епта.

Томпсона? который Гонзo?

> А ведь Вирт давно уже предлагал создавать модульные системы! Там зависимости тоже есть, но куда слабже, чем линуксовые крюки.

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

> Тем не менее, возможно что все 100% линуксовых поделий компилятся именно мэйком. смишно...

дадада, первые 100% make-ом, вторые 100% scons'ом, ещё 30% Jam'ом (который в отличие от make-а однопроходной, но синтаксис надо вкурить), четвёртые 100% waf/aap/etc.