我们有一个软件基础架构，其工作方式与软件构建系统非常相似：信息从不同来源收集并用于生成一些输出。与传统的软件构建一样，我们有不同类型的输出，依赖树等。
主要区别在于我们的来源，中间结果和输出本质上不是基于文件的。相反，它们是（唯一可寻址的）数据对象。
现在我们正在将我们的数据结构映射到文件和目录，并结合传统的构建系统（SCons）但不能扩展，两者都是w.r.t.表现但（更重要的是）w.r.t.可维护性。因此，我正在寻找一种从头开始为此目的而构建的基础设施。
例如，假设您有3个XML文档A，B和C。假设B/foo/bar是从A/x/y和A/x/z计算的，同样C/a/b是从A/x/y计算出来的。我需要一个基础设施
使用文件的一个主要问题是，如果我将A，B和C映射到某些文件A.xml，B.xml和{{1使用传统的构建系统，然后对C.xml的任何更改都会触发重建A.xml和B.xml，即使C.xml和A/x/y（A/x/z的原始依赖项）未被修改。因此，对于细粒度的依赖关系解析，我需要将B，A和B中的每一个映射到一个文件，而不是映射到每个子目录代表一个元素的目录，文件代表属性等。正如我所说，这不适合我们。
（请注意，我们的系统实际上并不基于XML）
现在我正在寻找指向这个方向的任何现有软件，基础设施或概念，无论实现语言和底层数据结构如何。
答案 0 :(得分：2)
因此，没有任何想法可以解决您的问题，但有一些工具可能会让您比现在更接近：
1）您可以使用Fuse将某些东西放在一起，这样可以更好地控制数据对象如何映射到文件。 Fuse基本上允许您从所需的任何后备数据构造任意文件系统。 （python bindings非常友好，但也有许多其他语言接口可用）。然后，您可以使用传统的构建工具，并利用与您的数据更好地关联的文件类对象。
2）Cmake有一种非常可扩展的语言，用于编写您可能能够投入使用的自定义目标。不幸的是，它的语言很有说服力，并且学习曲线陡峭，所以它不是我的第一选择。
答案 1 :(得分：2)
听起来你需要一个活跃的对象数据库管理系统（ODBMS），如GemStone/S。 ODBMS提供传统的持久性服务，而没有将数据结构映射到文件的旧成本以及对象技术的众所周知的好处。正如您所提到的依赖树和可寻址对象，在ODBMS中，导航引用存储为其数据的一部分，允许表示/访问对象之间的任何复杂交互模式。当您预测使用继承，对象嵌套和交叉引用的系统时，尤其如此。
虽然对象引擎可能看起来超出您的要求，但大型生产业务系统通常在并发和多用户环境中使用OODBM存储和执行方法。它不是免费的，因为你必须投资于人类的等式（教育和经验），但一旦最初的恐惧被克服，它将支付投资的回报。
为了在更改（播音员的通知）后重新构建（订阅）部分，您可以使用Observer design pattern或其中一个变体（SASE或Announcements framework），实施您的宣布/订阅架构。在这种类型的事件框架下，传统的基于文件的解决方案很难解决这些内在问题，正如您已经注意到的那样。例如，通常情况下，依赖机制可以管理对象的替换，或者在您的示例中管理另一个对象的替换。任何现代事件框架都应该在删除对象时进行管理，插入旧对象的所有依赖项都将更新为新引用。
最后，有一个免费的GemStone/S stack，其中包含对象依赖框架，因此您可以尝试使用真实的对象数据库。