hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								Главаm		10. Код, который построил Джек
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

Вопросы личного характера

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
631Click										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

1.Умеете ли вы выполнять различные виды компиляции с помощью своей системы сборки? Каким образом можно собрать из одного и того же источника и с помощью одних и тех же make файлов и отладочную, и финальную версии продукта?

Водном из предыдущих ответов мы видели хорошее решение этой про% блемы: собирать объекты в разных подкаталогах с помощью сценари% ев сборки исходя из типа сборки (один каталог для отладочных фай% лов, другой для окончательных).

ВGNU Make этого можно достичь с помощью имен файлов. Например:

# Определим исходные файлы SRC_FILES = main.c func1.c func2.c

#Тип сборки по умолчанию (если не указан) BUILD_TYPE ?= release

#Создаем имена объектных файлов

#(Это формула GNU Make, которая меняет

#суффикс .c на суффикс .o)

OBJ_FILES = $(SRC_FILES:.c=.o)

#А теперь хитрость: добавим к именам объектных

#файлов префикс (чудеса GNU Make)

OBJ_FILES = $(addprefix $(BUILD_TYPE)/, $(OBJ_FILES))

Очевидно, что для выбранного типа сборки (BUILD_TYPE) можно поме% нять и другие параметры, например флаги компилятора. Не забудьте, что понадобится правило, которое создаст подкаталоги, иначе компи% лятору некуда будет писать результат. Вот как это делается в UNIX:

$(BUILD_TYPE):

mkdir p $(BUILD_TYPE)

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

BUILD_TYPE=release make all

BUILD_TYPE=debug make all

Можно сделать более простую систему без этой техники подкаталогов, но в ней придется делать чистку при каждом изменении BUILD_TYPE.

2.Хороша ли система сборки в вашем текущем проекте? Обладает ли она качествами, о которых говорилось в этой главе? Можно ли ее усо вершенствовать? Легко ли будет:

a.Добавить новый файл в библиотеку?

b.Добавить новый каталог в код?

c.Удалить или переименовать файл с кодом?

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
w Click								632m
w
	w								o
	.							.c
		p					g
			df			n		e
				-xcha

				hang		e
			C				E
		X
	-							d
	F								t
	D								i
									r
P						NOW!			o
					BUY
				to
Ответы и обсуждениеClick										m
w									o
	w
w								.c
	.
		p					g
			df			n		e
				-x cha

d.Добавить новую конфигурацию сборки (например, для демонстра ционной версии)?

e.Собрать две конфигурации по одному экземпляру исходного кода, не зачищая дерево в промежутке между сборками?

Это говорит о том, насколько хорошо вы знаете процесс сборки и на% сколько легко его сопровождать. Полезно сравнить свой механизм сборки с другими проектами – тогда вы увидите, где ваши процессы неадекватны и требуют усовершенствования.

Возьмем, к примеру, перемещение и переименование исходных фай% лов. То и другое часто незаметно происходит при рефакторинге. Эти простые действия могут привести к некорректному определению систе% мой зависимостей и к сборке кода с ошибками. Я сталкивался с такими проблемами неоднократно; не сразу замечаешь возникшие проблемы.

Часто у программистов «нет времени», чтобы поправить систему сбор% ки; они слишком спешат выдать готовый продукт. Это опасное заблуж% дение. Сценарии сборки составляют часть кода и так же требуют со% провождения и развития, как любые другие исходные файлы. Надеж% ность и безопасность системы сборки настолько важны, что нельзя считать потерянным время, потраченное на их доработку. Это время – ваши инвестиции в базовый код.

3.Приходилось ли вам когда либо создавать систему сборки с самого на чала? Чем вы руководствовались при ее конструировании?

Как и в любой задаче программирования, на ваше решение оказывают влияние многие факторы:

•Ваш прежний опыт

•Ваши знания

•Ваше текущее представление о задаче

•Ограничения существующей технологии

•Имеющееся время

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

•Меняются требования – если проект действительно оказывается ус% пешным, могут потребоваться версии на разных языках или для других архитектур процессора. Система сборки должна допускать расширение.

•Может потребоваться перенесение кода на новую инструменталь% ную цепочку сборки, хотя никто и никогда не предполагал, что та% кой вариант возникнет.

Легкость, с которой могут быть сделаны эти модификации, служит свидетельством качества вашего проекта. Каждое изменение способст%