Настройка SCons для иерархического источника, но одной цели - PullRequest
Новая
       5

Настройка SCons для иерархического источника, но одной цели

5 голосов
/ 11 января 2012

У меня есть проект на C ++ / Python, над которым я работаю, и до сих пор полагался на Visual Studio для управления сборками.Теперь я хочу автоматизировать процесс сборки, надеюсь, включить поддержку нескольких платформ (это все стандарт C ++ / Python), и думаю, что SCons может быть инструментом для выполнения этой работы.

В этом задействовано много исходных файлов,несколько каталогов, но (стерео) типичный пример выглядит следующим образом: 

foo.lib
  directory_1
    bar1_1.cpp
    bar1_2.cpp
    ... etc. ...
  directory_2
    bar2_1.cpp
    bar2_2.cpp
    ... etc. ...

Итак, другими словами, исходные файлы находятся в иерархии, но есть только одна цель.(Иерархия совпадает в пространствах имен, используемых в коде, но для целей этого вопроса это излишне.)

Мой вопрос: каков наилучший способ структурировать файлы SConstruct и SConscript?Я прочитал документацию по SCons, в частности, раздел Hierarchical Builds и идею использовать несколько файлов SConscript с подходящими вызовами 'SConscript'.Все кажется ясным и особенно опрятным.Однако, казалось бы, это предназначено для иерархии с несколькими целями.Могу ли я использовать эту же функцию там, где есть только одна цель?

(я думал о файле SConstruct / SConscript верхнего уровня, по крайней мере для рассматриваемой библиотеки, перечисляя весь исходный файл с подкаталогами, но«чувствую» лучший способ сделать это. Может, действительно, это путь вперед?)

Большое спасибо заранее за любой совет / понимание.

Ответы [ 2 ]

5 голосов
/ 11 января 2012

Я несколько раз использовал иерархическое решение, очень похожее на то, которое вы описываете. Я выбрал решение, подобное этому:

в SConscript: 

#/bar/SConscript
Import("env")
env = specialize_env_for_this_subpackage()

myfiles = Glob(*.cpp)
apply_any_exclusions(myfiles)
myobjects = env.Object(myfiles)

Return(myobjects)

затем в SConstruct: 

#SConstruct
env = construct_general_environment()

subpackages = ["foo","bar","baz"] #or perhaps call your own find_subproject() function

objects = SCons.Node.NodeList
for package in subpackages:
    pack_objects = env.SConscript(os.path.join(package,"SConscript"), exports = env)
    objects.extend(pack_objects)
program = env.Program("myprog",objects)

Default(program)

Затем вы точно настраиваете контроль над средой в каждом пакете, и при грамотном использовании папки * site_scons * вы можете предотвратить повторение одних и тех же строк для каждого сценария. Еще одним преимуществом этого подхода является то, что файлы scons отражают дизайн. Я также предпочитаю использовать Glob для сбора файлов cpp, что позволяет мне добавлять и удалять файлы по своему усмотрению, не редактируя файлы сборки для таких тривиальных операций.

0 голосов
/ 11 января 2012

Нет ничего плохого в том, чтобы перечислить все исходные файлы в один SConstruct файл.Иерархическое структурирование SConscripts также хорошо, но вам нужно будет возвращать объекты из каждого слоя, что будет немного глупо: 

# SConscript, for example
sources = ["bar1_1.cpp", "bar1_2.cpp", ...]
objects = [env.Object(x) for x in sources]
Return(objects)

# SConstruct (top-level)
directory_1_objects = SConscript("directory_1/SConscript")
directory_2_objects = SConscript("directory_2/SConscript")
program = env.Program("magical_wonders", [directory_1_objects, directory_2_objects])

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

...