我正在写一些类似C ++的交互式教程。本教程将由两部分组成:一个部分编译到一个库中(我正在使用Scons进行构建),另一部分(本课程)随该教程一起提供,由最终用户进行编译。我目前正在寻找一种简便易行的方法供人们学习这些课程。
基本上,第二部分是一个目录,其中包含所有课程,每个课程都位于其自己的目录中。每节课至少有一个lesson.cpp和一个main.cpp文件,可能还有其他文件,这些文件的存在直到发行后我才知道,最终用户将创建这些文件。它看起来像这样:
all_lessons/
helloworld/
lesson.cpp
main.cpp
even_or_odd/
lesson.cpp
main.cpp
calculator/
lesson.cpp
main.cpp
user_created_add.cpp
其中的每一个都需要按照几乎相同的规则进行编译,并且编译命令应该可以从课程目录之一(helloworld/等)运行。
看到该项目的其余部分是由Scons构建的,将其用于此部分也很有意义。但是,Scons SConstruct在其运行目录中搜索文件:将SConstruct文件放在每个课程目录中,再加上给出一般规则SConscript的all_lessons/目录中的文件,是否可以接受?这似乎与Scons期望组织项目的典型方式背道而驰:这种方法的潜在陷阱是什么?我可以放置一个SConstruct文件而不是SConscript文件,从而可以从这两个目录中进行构建吗(我猜测是使用导出以避免无休止的递归)?
另外,我可能在某一时刻要替换lesson.cpp一个lesson.py生成所需的文件; Scons是否可以让我轻松地与建筑商一起使用,还是有一个更方便的框架?
最后,我想得出以下结果(或等效于不同的构建系统):
all_lessons/
SConstruct
helloworld/
SConstruct
lesson.cpp
main.cpp
even_or_odd/
SConstruct
lesson.py
main.cpp
calculator/
SConstruct
lesson.cpp
main.cpp
user_created_add.cpp
scons all在all_lessons目录中运行需要:
运行even_or_odd/lesson.py生成even_or_odd/lesson.cpp。
意识到user_created_add.cpp还需要编译。
为每个课程生成一个可执行文件。
scons在even_or_odd/,或scons even_or_odd中运行all_lessons/将产生与以上命令相同的可执行文件(相同的编译标志)。
摘要:
Scons是否适合/能够做到这一点?
SConscript文件上方的SConstruct文件时,Scons是否工作正常?
Scons是否可以很好地与SConstrcut一个项目的多个文件相互兼容?
Scons构建器系统是否适合使用Python脚本生成C ++文件?
使用其他构建系统/编写自己缺少的构建框架有什么优势吗?
任何进一步的评论,当然是受欢迎的。
谢谢。
当年话下
相关分类