В make-файле, когда мы используем.o файлы?

Обновление:

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

Если страницы в книге все пронумерованы так или иначе, почему беспокойство с книгами? Если я хочу прочитать книгу, я могу просто взять страницы, правильно? Если.c +.h файлы являются отдельными страницами, то .o-файлы похожи на главы. Они - вид - автономных объектов машинного кода, но не имеют к (и часто делают не) имейте смысл самостоятельно. Они - предварительно скомпилированные объекты, которые должны быть переданы компоновщику, который соединит их так, все это имеет смысл.

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

Помещенный просто, если бы необходимо было записать, и затем скомпилировать программу, сказать клиент MySQL, необходимо было бы написать запрашивающий DB код отдельно из кода, который имеет дело с материалом фронтенда/GUI.

При помещении их всех в единственный файл это была бы правильная путаница, и, и при этом Вы не сможете снова использовать любой код. По крайней мере, не легко.

Путем разделения уровня GUI кода, например, можно использовать код, Вы записали, что тянет кнопки для Вашей следующей программы.

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

gtk_window_set_default_size(GTK_WINDOW(window), 230, 150);
gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
gtk_window_set_icon(GTK_WINDOW(window), create_pixbuf("icon.png"));
MYSQL *connection = mysql_init(NULL);
if (connection == NULL) exit(EXIT_FAILURE);

Смешивание в бэкенде и материале GUI просто ужасно каждым способом.

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

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

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

Когда Вы компилируете, особенно когда все еще разрабатывают/отлаживают/тестируют Ваш код, Вы хотите, чтобы фаза компиляции была быстра. Только скомпилируйте то, что Вы изменили, легко путем хранения.o файлов тех исходных файлов, которые не были изменены.

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

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

• Отладка легче, если компоновщик подбрасывает ошибки, Вы знаете, где посмотреть.

Когда Вы компилируете код, который не содержит a main функция, Вы получаете ошибку. На самом деле это - компоновщик, который генерирует эту ошибку. Это просматривает все объекты, которые это должно соединить для создания двоичного файла, в поисках всех символов, на которые полагается программа.
Если нет main символ должен быть найден где угодно, программа не имеет никакой начальной точки и таким образом не может работать. Компилятор не требует этой функции, поскольку довольно радо скомпилировать код в неавтономный.o файл. Компоновщик выкладывает программу, и если там, main функция не может быть найдена, она не может продолжиться.

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

Да ведь затем, не изменяют make-файл, после того как Ваш код готов быть выпущенным?

• Почему беспокойство?
• Если Ваш make-файл общедоступен, вероятно, Вы имеете дело с проектом с открытым исходным кодом. В течение дня все, кто интересуется кодом, сделают его собственный make-файл (который не помогает проекту С открытым исходным кодом->, стандарты важны). компиляция партии в 1 идет, не делает Вашу товарищескую встречу С открытым исходным кодом проекта: никто не может чинить далеко в 1 данной части кода, не имея необходимость постоянно перекомпилировать партию. Почему Вы провели бы время и усилие раздражать возможных участников?
• Make-файлы должны считаться кодом: сделайте их легкими читать, ради Вас и наш. Если у Вас будет 5 подмодулей, каждый в зависимости от где-нибудь между 5 и 10 параметрическими усилителями, имеющими необходимость быть переданными gcc, то Ваш make-файл будет похож на путаницу.
• Когда Вы компилируете программу, которая имеет больше чем 2 файла, которым нужно соединение, кто должен сказать, что все файлы должны быть связаны друг с другом, таким же образом? Не только, что, кто должен сказать, что Вы хотите все файлы, сами скомпилированные таким же образом? В зависимости от выпуска, или если Вы имеете дело с проектом, который поддерживает расширения, которые можно иметь необходимость для компиляции различных битов источника по-другому, и в заданном порядке.
• Если это - проект с открытым исходным кодом: если Ваш код основывается на Вашей системе, которая означает, что у Вас есть все зависимости наготове. Другие не могли бы. Make-файл (идеально, у Вас есть файл конфигурации, также) может сказать людям, стремящимся попробовать независимо от того, что Вы сделали, в каких зависимостях они испытывают недостаток

Возьмите это, например:

MAIN   ===> API ==> MySQL
  |          /\      /
  |  --->  std*  ---/
  v        /
 GUI -----/
  |
  v
 GTK+

Ваш make-файл скомпилировал бы код MySQL API +, GUI + код GTK полностью отдельно, и затем связал бы их всех вместе на "ОСНОВНОЕ" примера, данного выше. Скомпилировать все сразу - ложь. Если API правильно написан, не должно иметь значения, если существует GUI или нет.

Как дело обстоит так здесь, Вы часто связываетесь с общими зависимостями. Это может произойти, что компоновщик нуждается в Вашей помощи для разрешения зависимостей правильно, хотя я не могу найти пример ATM. Это одно силы Вы, чтобы скомпилировать на шагах и таким образом записать make-файл.

Затем существуют статические зависимости. Я просто оставлю Вас с этой ссылкой, которая делает отличную работу при объяснении этого, и после того как Вы прочитываете его, у Вас должно быть хорошее понимание того, почему make-файл так ценен.

Это также работает, когда существует нет .c файлы для генерации .o файлы от. И если .c есть ли и .o не, это берет встроенные неявные правила генерировать их.

Ваш пример, кажется, оттянут из популярного учебного руководства, как: http://www.cs.colby.edu/maxwell/courses/tutorials/maketutor/ (или Google для "hellomake.o hellofunc.o"), в котором показывают несколько уровней стиля. Решающее различие - или ли зависимости явно неявно выражаются. Таким образом (из того учебного руководства):

hellomake: hellomake.c hellofunc.c
        gcc -o hellomake hellomake.c hellofunc.c -I.

hellomake: hellomake.o hellofunc.o
        $(CC) -o hellomake hellomake.o hellofunc.o -I.

Первый случай говорит, что hellomake конечный файл должен быть не более старым, чем *.c файлы - и дает порождающее правило, которое всегда перекомпилировало обоих *.c файлы в цель. (который подразумевает, что *.c файлы будут перекомпилированы для создания *.o файлов, которые могут быть загружены в hellomake конечный файл.)

Второй случай говорит, что hellomake конечный файл должен быть не более старым, чем *.o файлы - и и дает правило, которое только загружает *.o файлы в hellomake конечный файл.) ($ (CC) знает для вызова загрузчика для *.o файлов).

Один подход к Make-файлам должен сделать большинство правил неявным - правила как:

foo.o should be no older than foo.c
compile a *.c to produce a *.o

или

foo: foo.c bar.c foo.h

Другой подход должен сделать много правил явными:

foo: foo.o bar.o
    gcc -o foo foo.o bar.o

foo.o: foo.c
    gcc foo.c

bar.o: bar.c
    gcc bar.c 

Я предпочитаю минимальный и краткий подход - экспресс как можно меньше зависимостей и позволяю, заставляют (1) использовать встроенные правила 'сделать правильную вещь'. Сделайте знает для вызова компилятора C, чтобы произвести *.o из *.c и назвать компилятор C для создания исполняемого файла из некоторых *.o файлов - все, что нам придется сделать, должен сказать это, какие *.c файлы должны быть не более старыми, чем который исполняемый файл.

Другой предпочитать очень явный и подробный подход.

Я размышляю, что это - шаблон, который развился в конце 1980-х, когда инструменты для генерации Make-файлов стали популярными, и они генерировали очень подробные Make-файлы, которые выразили каждую зависимость, и затем люди начали подражать тому стилю в рукописных Make-файлах.

(Форматирующий примечание - порождающие правила в Make-файлах должны быть расположены с отступом с Символом табуляции.)