Автоинструменты: генерация исходников и заголовков в Makefile.am

Question

Эта ссылка упоминает подстановочные знаки как способ автоматического перечисления ИСТОЧНИКОВ и ЗАГОЛОВОК в файле Makefile.am. Также упоминается, что некоторые люди пишут внешние скрипты для генерации этих файлов.

Знаете ли вы о стандартном способе автоматического включения всех * .h * .cpp здесь, или я должен просто написать свой собственный скрипт Perl для их генерации. У вас уже есть такой скрипт, который вы используете?

PS: Исходные файлы в моем проекте организованы в соответствии со следующим чисто логическим разделением каталогов:

src/dog/woof.h
src/dog/woof.cpp
src/cow/moo.h
src/cow/moo.cpp

Answer 1

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

Например, у меня были проекты, которые были изложены как

src/module/code
src/app/code
src/library/code
include/headers

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

В проектах много вариаций. Некоторые хранят общедоступные заголовочные файлы в частных каталогах, а некоторые хранят их отдельно. Некоторые создают общие библиотеки объектов, некоторые нет. Некоторый код корабля, который НЕ ПРЕДЛАГАЕТСЯ компилировать на несовместимых платформах.

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

Если вы считаете это недостатком automake, это нормально; тем не менее, это один из тех недостатков, которые автоматизирует использование, поскольку он сохраняется в стремлении сделать вещи более гибкими. Automake не навязывает «как» вы делаете вещи, он предоставляет множество вспомогательных инструментов, но он делает все возможное, чтобы гарантировать, что вы не будете вынуждены использовать один «метод» компоновки или построения кода.