Как добавить тестовый модуль в проект общей библиотеки с помощью автоинструментов
Я разрабатываю библиотеку, которая должна делать много расчетов. Используется система сборки GNU autotools. Существует тестовый проект, который ссылается на эту библиотеку и выполняет различные процедуры тестирования. Каждая процедура сравнивает результаты с предварительно рассчитанными значениями из MATLAB.
Я обнаружил, что процесс тестирования скучен и занимает много времени. Каждый раз, когда мне нужно сделать make, sudo make install в библиотеке и make в тестовом проекте, затем запустите программу и посмотрите, что происходит.
Какой стандартный способ добавить check целевая библиотека с помощью автоинструментов? Это должно соответствовать этим требованиям:
- Пользователь должен иметь возможность
make checkи увидеть результаты без необходимости установки самой библиотеки. Исполняемый файл должен ссылаться на недавно скомпилированные и еще не установленные общие объекты. - Бег
make checkТакже следует запустить тестовую программу. (Не только скомпилировать его). Результатmake checkзависит от возвращаемого значения тестовой программы. Марка должна показывать ошибку, если тестовый модуль не работает. - Если пользователь решает не
make checkтогда исполняемый файл не должен быть скомпилирован.
Решение
Поскольку вы уже используете автоинструменты, у вас уже есть большая часть инфраструктуры. Я не знаю макет каталога, но скажем, у вас есть: SUBDIRS = soroush tests на высшем уровне Makefile.amальтернативно, вы могли бы иметь SUBDIRS = tests в soroush каталог. Важно то, что управляемый libtool libsoroush.la существует до спуска в tests каталог.
Префикс check_ указывает, что эти объекты, в этом случае PROGRAMне должен быть построен до make check это запустить. Так в tests/Makefile.am => check_PROGRAMS = t1 t2 t3
Для каждой тестовой программы вы можете указать: t1_SOURCES = t1.cc, и т.д. В качестве ярлыка, если у вас есть только один исходный файл на тест, вы можете использовать AM_DEFAULT_SOURCE_EXT = .cc, который будет неявно генерировать источники для вас. до сих пор:
AM_CPPFLAGS = -I$(srcdir)/.. $(OTHER_CPPFLAGS) # relative path to lib headers.
LDADD = ../soroush/libsoroush.la
check_PROGRAMS = t1 t2 t3
AM_DEFAULT_SOURCE_EXT = .cc
# or: t1_SOURCES = t1.cc, t1_LDADD = ../soroush/libsoroush.la, etc.
make check будет строить, но не выполнять эти программы. Для этого вам нужно добавить:
TESTS = $(check_PROGRAMS)
Что действительно хорошего в этом подходе, так это то, что если libsoroush построен как разделяемая библиотека, libtool позаботится об обработке путей поиска в библиотеке и т. д., используя неустановленного библиотека.
Часто в результате t1 Программа будет просто сценарий оболочки, который устанавливает переменные среды, так что реальный двоичная: .libs/t1 может быть выполнен Я только упоминаю об этом, потому что весь смысл использования libtool заключается в том, что вам не нужно беспокоиться о том, как это делается.
Проверка обратной связи сложнее, в зависимости от того, что вам требуется. Вы можете пройти весь путь с помощью параллельного тестового жгута или просто обратной связи PASS / FAIL. Если тестирование не является серьезным узким местом или проект огромен, его проще использовать просто (или скриптовое) тестирование.
Другие решения
Других решений пока нет …
detector