Как реализовать цель make installcheck
при создании библиотеки? То есть у меня есть цель check
, которая создает тестовую программу, которая ссылается на созданную библиотеку, вызываемую каким-то скриптом, чтобы проверить, правильно ли работает код библиотеки, и я хочу выполнить те же проверки, но ссылаюсь на библиотеку после он был установлен; как я могу это реализовать?(GNU make) installcheck a library
ответ
Поскольку мой вопрос не получил ответов, и я не могу легко найти что-либо на трубках, и потому, что мой метод хотя бы работает (хотя это может быть немного уродливо), я отвечу на свой вопрос с помощью общего метода I используемый.
Если процедуры проверки для создания библиотеки связаны с привязкой библиотеки к тестовой программе и наблюдением, правильно ли работает эта программа, то для установкиcheck библиотеки нам нужно сделать только то же самое, но скорее связывать тестовую программу с установленной библиотекой чем локально построенная библиотека.
Назовём библиотека альфа (так мы будем создавать libalpha.so и/или libalpha.a). Исходный код, предполагающей Альфы находится в файле alpha.cpp в Src каталога, мы создадим SRC/Makefile.am как обычно:
# src/Makefile.am
lib_LTLIBRARIES = libalpha.la
libalpha_la_SOURCES = alpha.cpp
include_HEADERS = alpha.h
Проверка процедура включает в себя создание бинарного бета, что ссылки на alpha. Исходный код для beta находится в файле beta.cpp в каталоге тестов. Automake файл тесты/Makefile.am выглядит следующим образом:
# tests/Makefile.am
check_PROGRAMS = beta
beta_SOURCES = beta.cpp
beta_CPPFLAGS = -I$(top_srcdir)/src
beta_LDADD = $(top_builddir)/src/libalpha.la
Мы добавим check
и installcheck
цели в тесты/Makefile.am как:
check-local:
# recipe to run when 'make check' is called.
installcheck-local:
# recipe to run when 'make installcheck' is called.
check
и installcheck
цели конфликта потому что использование любой цели предотвращает правильную выполнение другой цели (одна цель «taints» дерева сборки для другой цели); для того, чтобы другая цель выполнялась должным образом, нам нужно удалить beta и ее объектные файлы и перетащить цель и повторно привязать ее по своему усмотрению (installcheck
к установленным файлам check
в локальные файлы).
Мы можем решить эту проблему испорченных строительных деревьев, просто выполнив make clean
в рецепте обеих целей. Это явно удалит испорченные сборки, но будет чрезмерным, потому что нам не нужно перестраивать, когда мы снова запускаем ту же цель. Дерево сборки только испорчено всякий раз, когда мы запускаем другую цель.
Мы можем решить только это осложнение, вспомнив, какая из двух целей была вызвана ранее, что мы можем сделать с помощью создания/уничтожения промежуточного файла (назовем его taint).Цель check
испорчена всякий раз, когда файл taint существует, который он решает путем очистки, восстановления и удаления taint; и цель installcheck
испорчена, когда файл taint не существует, который он разрешает путем очистки, восстановления и создания taint.
Наши цели будут иметь вид:
check-local:
# First, check to see if the build tree is tainted and rebuild if so
test ! -f taint || $(MAKE) $(AM_MAKEFLAGS) check_rebuild
# Then, run our check tests
check_script.sh --bin=./beta --scenario=1
check_script.sh --bin=./beta --scenario=2
...
installcheck-local:
# First, check to see if the build tree is tainted and rebuild if so
test -f taint || $(MAKE) $(AM_MAKEFLAGS) installcheck_rebuild
# Then, run our installcheck tests
check_script.sh --bin=./beta --scenario=1
check_script.sh --bin=./beta --scenario=2
...
Мишень check_rebuild
необходимо восстановить в соответствии с тем, как check
будет работать, и будет выглядеть следующим образом:
.PHONY: check_rebuild
check_rebuild:
$(MAKE) $(AM_MAKEFLAGS) clean # remove tainted build tree
$(MAKE) $(AM_MAKEFLAGS) beta$(EXEEXT) # rebuild beta
rm -f taint # mark build tree as untainted
Мишень installcheck_rebuild
также выглядит это:
.PHONY: installcheck_rebuild
installcheck_rebuild:
$(MAKE) $(AM_MAKEFLAGS) clean # remove tainted build tree
$(MAKE) $(AM_MAKEFLAGS) beta$(EXEEXT) \
alpha_CPPFLAGS="-I$(DESTDIR)$(includedir)" \
alpha_LDADD="$(DESTDIR)$(libdir)/libalpha.la" \
alpha_DEPENDENCIES="$(DESTDIR)$(libdir)/libalpha.la"
echo 1 > taint # mark build tree as untainted
Обратите внимание, что при перестройке beta в installcheck_rebuild
теперь требуется переопределение автоматических переменных, чтобы они указывали на установленную библиотеку.
И это должно быть так. Цели check-local
, installcheck-local
, check_rebuild
и installcheck_rebuild
в их окончательной форме выше должны быть размещены в любом месте файла тестов/Makefile.am в дополнение к любым другим командам там.
- 1. создание версии GNU GNU make
- 2. `make зависит от магии в gnu make?
- 3. GNU Make: запрошенный target
- 4. GNU make цитирует
- 5. Mutex в GNU Make?
- 6. gnu make игнорировать .INCLUDE_DIRS?
- 7. GNU Make Соответствующие списки
- 8. GNU make wildcard альтернатива?
- 9. Отладка GNU make
- 10. Многострочное определение в GNU make
- 11. GNU make wildcard variable target
- 12. Makefile: Linking. * A library
- 13. Обновление GNU make на macOS
- 14. GNU make и список объектов
- 15. Всесторонний gnu make/gcc tutorial
- 16. GNU Make игнорирует Неявные правила
- 17. Parallelizing ant like GNU Make?
- 18. Использование GNU Make с подкаталогами
- 19. Как работает «файл» GNU make?
- 20. GNU make auto dependency generation
- 21. GNU make: инвертирует успех подпроцесса?
- 22. Записывать имена в GNU make
- 23. Minimal GNU Make система сборки
- 24. GNU MAKE: функции в зависимостях
- 25. Распределенный GNU Make for Win32
- 26. GNU make variables в Makefile
- 27. Понять объявление make-файла gnu
- 28. Зависимость проблемы с gnu make
- 29. GNU Make, построение ненужных зависимостей
- 30. Boost bjam против GNU make