Scons - использование настраиваемого препроцессора с кешем scons

В настоящее время я пытаюсь создать систему сборки на основе Scons, которая будет использовать драйвер Boost Wave в качестве специального препроцессора кода C ++. После предварительной обработки код компилируется с помощью MSVC. На данный момент я запускаю волну для каждого исходного файла, видимого Scons, из файла Sconscript. Это работает, но имеет проблему - это довольно медленно, потому что не использует кеш компиляции Scons.

Как бы вы порекомендовали интегрировать пользовательский шаг предварительной обработки в систему сборки SCons таким образом, чтобы использовался кеш компиляции? Очевидно, мне также нужно правильное сканирование зависимостей #include, параллельная компиляция и т. Д. Я не очень разбираюсь в SCons, поэтому ищу кого-нибудь, кто укажет мне правильное направление.

В настоящее время я занимаюсь двумя направлениями исследований:

  • Найти способ вызвать функции кеширования ввода / вывода вручную, но это рискованно - я не хочу загрязнять кеш недопустимыми записями.
  • Создание специального инструмента / псевдобилдера / чего-то, что позволило бы мне выполнять две команды. Или попробуйте заставить бра использовать два инструмента / псевдостройки. Это кажется сложным.
  • Ответ Тома Таннера, который, похоже, страдает от неправильного определения зависимостей #include.

person Liosan    schedule 16.08.2013    source источник


Ответы (1)


Чтобы использовать кеш scons, у вас должна быть цель. scons кэширует цель на основе добавленных файлов и команды сборки.

Даже без компоновщика вы можете написать себе командный процессор примерно так.

out_cc = env.Command('file.wave.cpp', 'file.cpp', 'wave command < $SOURCE > $TARGET')
env.Program('myprog', ['this.cc', 'that.cc', out_cc])

Это будет использовать кеш.

Вы можете добавить конструктор, если хотите, чтобы сделать это за один шаг. Строители хороши тем, что вы будете использовать одну и ту же команду в нескольких местах или иметь более сложные требования, чем можно описать с помощью простой команды. Однако они не важны для работы кеша.

Изменить: обновлено, чтобы включить решение liosan для волнового приема файлов .cpp и создания файлов .cpp и, следовательно, правильного включения зависимостей. Я отчаянно нуждаюсь в репутации ...

person Tom Tanner    schedule 16.08.2013
comment
Выглядит многообещающе, я изучаю это. Но как SCons узнают, что он должен скомпилировать предварительно обработанный файл? - person Liosan; 16.08.2013
comment
Эм, может быть, я неправильно его читаю, но после того, как я применил ваш фрагмент в нашей системе сборки, у меня появилась ошибка типа «Я не знаю, что делать с файлом X.wave», неожиданное расширение «волна» .. . - person Liosan; 16.08.2013
comment
На самом деле я использовал env.Command ('out.cpp.wave', 'out.cpp', ...), так что это объясняет. В настоящее время ваше решение работает с использованием env.Command ('out.cpp.cpp', 'out.cpp', ...), что приемлемо, если не идеально. Есть ли способ заставить scons узнать, что файлы .wave похожи на файлы .cpp? - person Liosan; 16.08.2013
comment
К сожалению, я обнаружил, что это решение не обнаруживает изменения неявных зависимостей :( (имеется в виду #include files). Поэтому оно бесполезно (то есть требует дополнительных исследований). - person Liosan; 16.08.2013
comment
Что ж, если волновые файлы имеют расширение cpp, по общему признанию, это будет довольно сложно. Вам нужно будет написать сканер (или, по крайней мере, сказать SCons, что ему нужно использовать C-сканер для волновых файлов). - person Tom Tanner; 16.08.2013
comment
В итоге я получил: out_cc = env.Command('file.wave.cpp', 'file.cpp', 'wave command < $SOURCE > $TARGET') Важные вещи, на которые следует обратить внимание: (a) Поскольку имя выходного файла отличается от имени входного, SCons не рассматривает его как цикл зависимости; и (б) файл по-прежнему заканчивается на .cpp, что означает, что сканеры зависимостей и компиляторы настроены правильно. Если вы обновите свой ответ, я помечу его как принятый :) - person Liosan; 20.08.2013