抱歉，这个问题在这里不合适，因为它至少部分征求意见。但是，有一个“最佳实践”标签，我相信答案可能是公众感兴趣的。
背景
在我们的工作组中，我维护了一个小包，其中包含一个类、几个包和 perl 脚本，总共约 4000 行代码。该包正在持续开发中。目前，我正在准备一个新的主要版本，其中包含一些新文件。
到目前为止，我都是将代码作为文件集合发布在目录或存档中。如果小组成员想要安装该软件包，则必须将每个文件复制到适当的位置。
随着新的修订，我想切换到更“TeXish”的开发：使用 .dtx 和 .ins 文件进行文学编程和捆绑安装。
问题
当我相信我了解了.dtx 文件的格式以及 docstrip 的工作原理，但我仍然对开发工作流程感到困惑。
与任何开发一样，我遵循一个开发周期：
编辑 - 编译 - 测试 - 提交（如果测试成功）。
经过几个这样的循环后，错误被消除或新功能被建立（并且可以发布新版本）。但是，如果源代码由一个或多个 .dtx 文件组成，则循环将至少包括一个额外的安装步骤。考虑到编辑更改通常相当小，额外的编译/安装似乎相当低效。
我考虑过几种选择，但发现都不太有吸引力：
- 使用一个大的 dtx 文件。坏处：编辑相当不方便，并且每个测试步骤都有额外的编译/安装步骤。
- 每个包和类使用一个 dtx 文件。坏处：现在我有更多的安装步骤。
- 使用
sty2dtx，不是在每个周期都使用，而是在功能已准备就绪时使用。坏处：几个，例如sty2dtx不能处理 LaTeX3 命令定义。 - 编写一种从源文件编译出.dtx文件的驱动程序，而源文件保留带有特殊注释的有效TeX/Perl文件。坏处：我不确定我的 TeX foo 是否足够。此外：我觉得，如果这是一个好主意，那么有人早就这么做了。
问题
什么是支持持续开发并生成安装包的良好 TeXish 工作流程？我是否错过了某个选项？
答案1
虽然可以.dtx“手动”处理源代码，但我认为最好将以这种方式设置的代码视为其他源代码程序关系：存在构建过程。这实际上与您使用单个.dtx还是多个无关（除了最小的项目外，我更倾向于后一种方法）。
源代码.dtx格式化后，提取可用代码、执行测试、安装等工作最好委托给构建工具。当然，您可以自己编写，也可以使用诸如 之类的系统。make但是，LaTeX 团队之所以能够开发，l3build正是因为构建 TeX 代码在某些方面与其他语言不同。这包括需要编写“匹配”的测试环境。使用l3build，检查修改后的代码片段非常简单
l3build check
如果你已经设置了测试，或者你想在本地安装并运行
l3build install
然后进行手动测试，并且可能
l3build uninstall
一旦你完成了。
请注意，虽然名称中l3build有 has ，但这是因为它是作为支持文件安装的工具编写的。但是，它旨在成为一种通用工具：它适用于各种代码结构，并且可以很好地与 LaTeX2e、纯代码甚至（在某种程度上）ConTeXt 代码配合使用。随着时间的推移，我们添加了一系列功能来支持不同的开发方法，包括自定义安装位置、非标准测试支持等。l3l3...