Вывод SCons в директорию сборки

Question

Я пытаюсь изменить мои файлы SCons так, чтобы они помещали сгенерированные файлы в каталог build .Изначально я, хотя VariantDir мог бы быть вариантом, но, судя по всему, что я прочитал, и из примеров, он не делает то, что я хочу.определенный каталог без необходимости переписывать все исходники и скрипты?

Answer 1

Поработав некоторое время с VariantDir (он вообще ничего не делал), я остановился на параметре variant_dir в вызове верхнего уровня SConscript, который приводит к тому, что все последующие выходные сборки в конечном итоге оказываются в параллельной «сборке».tree: SConscript(['subdirs/SConscript'], variant_dir='build', duplicate=0) Моя структура сборки представляет собой иерархию SC-сценариев в подкаталогах / под-подкаталогах и т. д. При этом вызове выходные данные заканчиваются в сборке / под-подкаталогах того же уровня, что и в источнике.

Это съедает один уровень, хотя (подкаталоги), и использование "../build" не помогает.Решение состоит в том, чтобы иметь файл SConscript на том же уровне, что и SConstruct, и вызвать SConscript(['SConscript'], variant_dir='build', duplicate=0)

См. Также Принудительно выводить Scons (exe, obj, lib & dll) в определенный каталог сборки -на него есть аналогичный ответ

Answer 2

Использование VariantDir с duplicate=0 должно работать.

Answer 3

Вы можете использовать Install или InstallAs на целевом выводе. У меня это работает.

lib = env.SharedLibrary(target = "some_target", source = sources);
env.InstallAs( target = "folder/output_name.ext", source = lib );

Answer 4

Столкнувшись с подобным разочарованием, я добавил site_scons, который добавил заменяющие компоновщики (например, «Exe» вместо «Program») и указал эмиттер для этого компоновщика, который заменил часть пути каталогом компоновки. Это требует использования альтернативного компоновщика во всех ваших SConscripts, хотя.

В качестве альтернативы вы можете попытаться создать подкласс Environment и переписать основные цели, чтобы использовать их переписывание. Затем вы указываете свою среду по умолчанию (изменяя Scons.Script.DefaultEnvironment или что-то в этом роде). Этот подход сохранял статичность SConscripts, но становился очень грязным и требовал большего обслуживания с течением времени, так как внутренности scons меняются.