AC>>>> Задача стояла построить _зависящую_ цель (пакет) при измениях в
AC>>>> исходных файлах _зависимых_ целей (конкретные программы). Эта
AC>>>> задача решена.
>>> Задача подразумевала некоторую вполне конкретную раскладку по
>>> директориям. А не как понравится тебе.
AC>> Извини подвинься. Вот уж каталоги я будут делать так, как удобно мне :)
AC>> В идеологии mk scripts: один проект (екзешник или библиотека) -
AC>> один каталог. Можно сделать как угодно, но оно того не стоит.
AC>> И это ОЧЕНЬ удобно.
> Нет, если ты можешь _естественно_ организовать проект по схеме "один
> проект - один файл на выходе", то да, наверное...
Один таргет файл условно. Есть понятие PROG - он один.
К нему можно добавить произвольное количество просто FILES
(mueller7.{dict,index})
или SCRIPTS (dictunformat.sh) и чего душе будет угодно.
PROG - это обычно екзешник или либа.
> Но это, насколько я могу понять, исключает unit tests
Нет, не отменяет.
Мухи отдельно, котлеты отдельно.
> (там по жизни
> несколько бинарников, да еще с шансами собираться и работать на разных
> платформах).
man bmake
/ .OBJDIR
/ MAKEOBJDIR
/ MACHINE
etc.
> Делать отдельный проект ("вот это - хрень, а вот это -
> тесты на хрень")?
Можно отдельным проектом, можно отдельным таргетом в зависимости от.
> А если мне надо пересобрать и перепрогнать один из
> тестовых бинарников?
В случае с несколькими полезными таргетами на каждый проект можно видоизменить
мое решение например так.
TRG?= all
.PHONY: dict dictd dictfmt dictzip
dict dictd dictfmt dictzip:
SUBDIR="libmaa dict_common $@" ${MAKE} ${TRG}
.include <bsd.subdir.mk>
Запускать так
bmake dict TRG=all_tests
Можно наоборот в переменную засунуть имя [под]проекта.
> Ну, то есть, допустим, у меня будет не project и project/t, а
> project и project_tests. Сиблинги. Ну, допустим, раз они сиблинги,
> даже можно сделать ../Makefile. И вот мне надо пересобрать один из
> тестовых бинарников после правки исходника в проекте, и прогнать его
> штатным образом.
Поставь проект "project_tests" в зависимость от проекта "проект".
Работать будет точно так же, как екзешник и либа.
Не принципиально.
> То есть создав ему развесистую среду и передав
> несколько штатных параметров. Общая длина командной строки -
> символов 200.
Какая разница, окружение передается вообще сорешенно прорачно.
env TEST_OPTS='options' TEST_ENV='oceans' bmake dict TRG=all_tests
где
dict/Makefile:
.PHONY: all_tests
all_tests : dict
env ${TEST_ENV} dict_test.sh ${TEST_OPTS}
> Сейчас у меня, с гнутым мейком, такой запуск делается отдельной целью в
> мейкфайле тестов.
> Она умеет пересобрать _свой_ бинарь.
Я уже ответил.
> В принципе, я готов на make all в собственно проекте, хотя тоже без
> лишней необходимости не хотелось бы. Но на прогон всех тестов я не
> готов, это минут 40.
разбей тесты на кучу подпроектов в зависимости от того, что они тестируют.
Далее каждому тесту - отдельный test_NNN/Makefile
И далее общий project_all_test/Makefile, объединяющий все тесты.
> Это как будет сделано в случае с nbmake?
Я уже ответил. Легко и непринужденно. Внимательно читаем непрочитанное
письмо. Принимаем идеологию "один проект - олдин каталог", это раз.
Пользуемся bsd.subdir.mk и вызываем $(MAKE) с модифицированной
переменной SUBDIR - два. Строим граф зависимостей между проектами,
по которому собственно и формируется SUBDIR - это три.
> И сразу, чтоб два раза не вставать. А как у этих замечательных скриптов
> с поддержкой кросс-компиляции?
NetBSD целиком и полностью строится на nbmake.
Собирается на всем что движется. Доподлинно собирается на FreeBSD и Linux.
То есть проблем никаких. Если есть где, то явно не в nbmake-е.
> На одной и той же машине с "родной", естественно. А с
> сосуществованием одновременно нескольких сборок под разные платформы
0 runawk>ls -la /tmp/runawk/
total 0
drwxr-xr-x 2 cheusov syntagma 40 2008-10-02 18:34 .
drwxrwxrwt 23 root root 740 2008-10-02 18:34 ..
0 runawk>env MAKEOBJDIR=/tmp/runawk bmake
gcc -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-uninitialized -Wreturn-type -Wcast-qual -Wpointer-arith -Wwrite-strings
-Wswitch -Wshadow -Werror -DAWK_PROG='"/usr/bin/awk"'
-DSTDIN_FILENAME='"/dev/stdin"' -DMODULESDIR='"/usr/local/share/runawk"'
-DRUNAWK_VERSION='"0.14.2"' -c /home/cheusov/prjs/runawk/runawk.c
gcc -o runawk runawk.o
pod2man -s 1 -r 'AWK Wrapper' -n runawk -c 'RUNAWK manual page'
/home/cheusov/prjs/runawk/runawk.pod > runawk.1
nroff -Tascii -mandoc runawk.1 > runawk.cat1
0 runawk>ls -la /tmp/runawk/
total 68
drwxr-xr-x 2 cheusov syntagma 120 2008-10-02 18:35 .
drwxrwxrwt 23 root root 740 2008-10-02 18:35 ..
-rwxr-xr-x 1 cheusov syntagma 20921 2008-10-02 18:35 runawk
-rw-r--r-- 1 cheusov syntagma 15655 2008-10-02 18:35 runawk.1
-rw-r--r-- 1 cheusov syntagma 12089 2008-10-02 18:35 runawk.cat1
-rw-r--r-- 1 cheusov syntagma 14516 2008-10-02 18:35 runawk.o
0 runawk>
Makefile на sf.net
> (исходники общие, раздаются по NFS - интересно, естественно,
типичный случай - source dir на read only.
Смотри выше. Условие: в каталоге с исходниками не должно быть мусора,
то есть частично построенного проекта. Он должен
быть ПОЛНОСТЬЮ ЧИСТ - только исходники.
AC>> тогда нечего задавать вопросы публично. Можешь пребывать в своем
AC>> неведении и дальше. Мне от этого ни холодно ни жарко.
> Ну, задачу-то я могу и дать. Ту самую, которую я не могу решить
> средствами make.
man bmake
/ [.]if
/ [.]for
> Там не только recursive, там еще и автогенерируемые
> зависимости
Зависимости между ПРОЕКТАМИ ставятся руками, их мало.
Между файлами - стандартный подход
bmake depend
>, и зависимость от параметров сборки (только что обсудили), и
> пересборка после cvs up, и чего-то еще веселенького до кучи...
Уже объяснял не раз - ЗДЕСЬ МИН НЕТ.
--
Best regards, Aleksey Cheusov.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
