Autoconf & CppUnit.

[dememax]

English version

Предупреждение: Этот пост не направлен на продвижение Autoconf'а и CppUnit'а. Возможно, вы узнаете, как существующий проект можно дополнить новой функциональностью.

Добавляем в configure.ac (или в соответствующий включаемый файл):

ifdef([AM_PATH_CPPUNIT], [AM_PATH_CPPUNIT([1.11.0])], [])

и добиваемся, чтобы aclocal увидел cppunit.m4 из поставки CppUnit'а.
Если пакет CppUnit установлен администратором системы, то aclocal должен вообще-то сам найти его. В противном случае, нужно ещё кое-что сделать, до чего я сам не сразу догадался.
Казалось бы, сообщил я autoreconf'у опцию '-I/путь/к/каталогу/с/м4' - и надеялся, что он передаст её aclocal'у сам, ан нет (далее подразумевается, что cppunit собран и установлен в домашний каталог опцией --prefix=/home/username):

username@hostname ~/works/project $ autoreconf -i -f -v -I /home/username/share/aclocal 
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
autoreconf: running: /usr/bin/autoconf --include=/home/username/share/aclocal --force
autoreconf: running: /usr/bin/autoheader --include=/home/username/share/aclocal --force
autoreconf: running: automake --add-missing --copy --force-missing
autoreconf: Leaving directory `.'
username@hostname ~/works/project $

понадобилось установить переменную среды:

username@hostname ~/works/project $ export ACLOCAL='aclocal -I /home/username/share/aclocal'
username@hostname ~/works/project $ autoreconf -i -f -v                                
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I /home/username/share/aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
autoreconf: running: /usr/bin/autoconf --force
autoreconf: running: /usr/bin/autoheader --force
autoreconf: running: automake --add-missing --copy --force-missing
autoreconf: Leaving directory `.'
username@hostname ~/works/project $

и теперь можно смело пользоваться опциями конфигурации "--with-cppunit-exec-prefix", используя совершенно разные установленные версии CppUnit'а, и переменными "CPPUNIT_CFLAGS" и "CPPUNIT_LIBS".
Теперь можно создать подпроект с тестами и целью 'check' с использованием CppUnit, для которого определить Makefile.am:

AM_CPPFLAGS = @CPPUNIT_CFLAGS@ ...
AM_LDFLAGS = @CPPUNIT_LIBS@ ...

ut_one_SOURCES = ut_main.cpp ut_one.cpp

ut_two_SOURCES = ut_main.cpp ut_two.cpp

## Target check - runs tests
UNITTESTS_PROGS = ut_one ut_two
noinst_PROGRAMS = $(UNITTESTS_PROGS)
check_PROGRAMS = $(UNITTESTS_PROGS)
TESTS = $(check_PROGRAMS)

Comments

[alexott.livejournal.com]

cmake лучше :-) boost.test, тоже :-)

Re: cmake лучше :-) boost.test, тоже :-)

[dememax]

Когда есть выбор - возможно! :-)

Я не знаю, как сейчас, но на некоторых платформах собрать boost - это была ещё та задачка...
Да и сейчас, смотрю, на моём дистрибутиве стали слотировать boost: видимо, есть разные проекты зависящие от разных версий boost'а.

Хотя, наверно, boost.test, как и boost.build, сам по себе ничего такого не тянет, а?

Re: cmake лучше :-) boost.test, тоже :-)

[alexott.livejournal.com]

по большому счету, да - не тянет. это можно проверить с помощью утилиты bcp из поставки буста

Re: cmake лучше :-) boost.test, тоже :-)

[alexott.livejournal.com]

у cmake основное преимущество - интеграция с ctest & cdash - тесты описываются рядом с библиотеками/программами, а результаты тестирования можно смотреть через CDash

Re: у cmake основное преимущество - интеграция с ctest & cdash - т

[dememax]

Я смотрю, это не единственное преимущество CMake'а.
Даже сам boost пытается использовать CMake.
Я так думаю, что лучшей интеграции в среду разработки придумать будет сложно, если вам система сборки генерирует родные понятные для среды файлы проектов. Хорошая концепция...