#c #waf
#c #waf
Вопрос:
Наш проект содержит много исходных текстов на c , до сих пор мы использовали make для сборки всего, однако это занимает много времени. Итак, я наткнулся на waf, который работает довольно хорошо и значительно ускоряет сборку. Однако каждый раз, когда я выполняю полную сборку, я получаю пару ошибок сборки, которые не имеют смысла. Если я выполняю инкрементную сборку сейчас, в большинстве случаев некоторые исходные коды, которые не удалось собрать с первого раза, создаются сейчас, некоторые другие по-прежнему терпят неудачу. При другой инкрементной сборке я, наконец, получу успешную сборку.
Я попытался создать отдельные библиотеки отдельными шагами, на всякий случай, если какие-либо зависимые библиотеки будут пытаться создавать параллельно, но ошибки все равно появляются.
РЕДАКТИРОВАТЬ: ошибки, которые я продолжаю получать, похоже, не имеют никакого отношения к моему коду, например
Build failed
-> task failed (exit status -1):
{task 10777520: c constr_SET.c -> constr_SET.c.1.o}
После очередной «сборки waf» я больше не получаю эту ошибку.
EDIT2: этап сборки для моих библиотек выглядит следующим образом:
def build(bld):
bld.shlib(source="foo.cpp bar.cpp foobar.cpp constr_SET.c",
target="foobar",
includes= "../ifinc",
name="foobar",
use="MAIN RW HEADERS",
install_path = "lib/")
MAIN, RW, ЗАГОЛОВКИ — это всего лишь некоторые флаги и внешние библиотеки, которые мы используем.
Кто-нибудь видел подобное поведение в своей системе? Или даже решение?
Комментарии:
1. Вы, по-видимому, неправильно определяете зависимости (возможно, на этапе ссылки). Но вы не показываете пример, даже ошибки, поэтому мы не можем помочь.
2. Вы, конечно, правы, обновленный пример. Это вполне может быть проблемой с зависимостями, однако эти ошибки продолжают появляться во время сборки наших разделяемых библиотек, которые не имеют никаких зависимостей друг от друга (мы копируем наши заголовки в центральный каталог, чтобы избежать зависимостей на этом этапе).
Ответ №1:
Я подозреваю, что несколько целей параллельно создают один и тот же требуемый объект. Попробуйте
export JOBS=1
или
waf --jobs 1
Комментарии:
1. Хорошо, вы попали в точку, если я уменьшу количество заданий, ошибки исчезнут. Но что я делаю не так? Я вставил (надеюсь) соответствующую часть моего wscript в текст вопроса.
2. Я думаю, вам следует показать правило, в котором компилируется constr_SET.c и / или где используется constr_SET.o . Я предполагаю, что более 1 двоичного файла ссылается на constr_SET.o и создает его по требованию — одновременно. В этом случае лучше явно зависеть от constr_SET.o, чтобы Waf мог знать зависимость и сериализовать зависимые правила
3. По сути, файл constr_SET.c является одним из исходных файлов для наших библиотек. Итак, в приведенной выше конфигурации компилируется исходный код, и поскольку наши библиотеки не зависят друг от друга, исходный код нигде не используется на этапе сборки библиотеки. Позже, когда наши процессы строятся, мы зависим от библиотеки, но я помещаю сборку библиотек и процессов в разные группы сборки, поэтому мне хотелось бы думать, что таких побочных эффектов не должно быть…
4. Просто повторно запустите сборку, и теперь я понял, что класс, для которого я получаю исключение, уже собран. По крайней мере, теперь я получил подсказку, в каком направлении искать. Большое спасибо, вы очень помогли.