Rodegast
Тю… оно же всё сишное! Ты мне для python проекта шаблон выложи.
Оно, главным образом, линуксовое. То есть под винду я это не готовил. Это не сложно, просто нафиг не нужно. Поэтому питоновские проекты точно такие же - make, m4, coverage3. Почему они такие - потому что make легко управляется не только со сборкой самого проекта, но и с установкой в систему, постановкой прав скриптам и так далее. Она вообще же разрабатывалась для unix-подобных операционных систем, поэтому она родная для линя и я её активно там юзаю. Web-приложение тоже есть на Flask'е, точно такое же всё, но там с тестами попроще, потому что питоновских тестов практически нет, есть только JavaScript-тесты, а в JavaScript-тестах я до покрывальщика так и не добрался, максимум смог получить моки. Покрывальщик там есть, но я его не догнал пока что. Просто в сишном проекте более забубённая компиляция, там два режима: можно просто скомпилировать программу; можно скомпилировать программу для просмотра через gdb. Вообще, первоначальная идея была сделать так, чтобы тесты можно было сделать просто и можно было сделать для просмотра в gdb (это разные опции при компиляции тестов нужно ставить). Но потом я посмотрел и оставил для тестов только вариант с просмотром в gdb, так как это дело не сильно отличается по объёму скомпилированных бинарников. В сишнике тесты - это программы, поэтому, если вдруг в тесте непонятная ошибка и неясно, в чём её причина, то тест надо дебажить в дебаггере. Естественно, чтобы дебажить тест, он уже должен быть скомпилирован с опцией дебага, иначе будешь тратить время, отвлекаться. В питоне такого нет, конечно, там всё проще из-за интерпретируемости.
Вот метод сборки для просмотра самой программы в gdb
./configure debug && make tests-coverage
То есть программа теперь может быть отлажена в gdb, а тесты всегда могут быть отлажены в gdb (такое решение было просто принято по мере использования проекта, хотя тесты изначально тоже можно было делить на два режима сборки).
Опция debug у ./configure заставляет при конфигурировании общего Makefile-файла пропустить его через другой файл для m4, который проставляет опцию -g в командах компиляции, записанных в Makefile-файле. Там возможностей куча в смысле путей достижения результата. Можно так параметризовать конфигурирование, а можно и по-другому. Есть широкий размах для творчества. Я все эти вещи долго продумывал разными путями. Это прямо как программу писать, составляя постепенно алгоритм, - почему и говорю, что это похоже на детектив.
Там ничего автоматически созданного нет, всё вручную написано методом проб и ошибок.
Так что можешь ковырять, чтобы понять, как оно организовано.
P.S.
Rodegast
Тю… оно же всё сишное!
Ты ещё не видел, что я недавно написал для проекта на C++/Qt - это был вообще полный капец, там же тоже юнит-тесты есть собственные, Qt-шные. Как написать сборку бинарника так, чтобы не надо было открывать QtCreator для сборки проекта? Но написал и сборку бинарника, и сборку юнит-тестов для него, и установку программы в систему с красивым значком в главном меню (значок ещё в Inkscape делал, тоже подучиться пришлось, хотя Gimp'ом владею давно; просто тут значки векторные и Inkscape сама по себе классной штукой оказалась). Вообще, все эти системные дела не такие страшные, как кажутся на первый взгляд. То есть вот есть у меня служба systemd своя в виде web-приложения, так я даже не думал, что установка собственной службы при “make install” с динамическим заданием имени программы будет проходить так просто, как получилось в итоге. Думал, будет сложнее все это.
В нём потом откроешь проект и выглядеть всё будет так, будто в нём всё это делал. То есть он становится просто не нужен.