配置文件的路径

创建时间:2019/1/12 下午5:07:39
编辑时间:2019/1/12 下午5:07:39
作者: huww98@163.com (huww98@163.com)
分类:

在软件体系结构课程上,我们知道延迟绑定是增强程序可修改性的有效办法。而使用配置文件,从配置文件中读取一些经常修改的内容可以显著减少软件重新编译的次数。但是没想到,如何可靠地从代码中找到配置文件却并不是一个简单的问题。

经过一段时间的思考,并调查了其他软件的实现方案,得出了以下一些可选的方案,以及他们各自的优缺点。

使用相对路径

该方案是最为简单的方案,在需要打开配置文件时只需在程序里写相对路径即可。但是相对路径是相对于当前工作目录的,但运行这个程序的人可能并不知道这一点,而使用了错误的工作目录,导致找不到配置文件。比如在开发阶段,我可能直接在build目录里运行./a.out,但我也很可能在源码目录里运行build/a.out

Spring Boot的配置文件支持以该方案读取。在Spring Boot中该方案主要用于设置一些部署环境特定的配置,作为其他方案的补充,而在部署后,可以使用一些方法来固定工作目录,因此,依赖当前工作路径的问题在部署后并不是很严重。

优点:实现简单

缺点:依赖当前工作路径

相对于二进制文件的路径

这种方法看起来非常美好,只要保持配置文件和二进制文件的相对位置不变,我们就始终可以找到配置文件。

事实上,Spring Boot,ASP.Net Core等框架的默认配置文件都是这样的。具体地,Spring Boot是相对于Java的class path, ASP.Net Core的是相对于AppContext.BaseDirectory 。但是C++编写的程序运行起来相对灵活,且并没有一个跨平台的,较为简单的方法能够确定当前二进制文件的位置。

优点:稳定,不易出错

缺点:没有简单的实现方式

使用绝对路径

乍一看好像这不是一个好方法,不是很灵活。但是调查后发现,Linux中的很多程序都从/etc目录中读取配置的,他们都是在编译时就确定了/etc这个绝对路径的。但是这个路径可以通过参数来在编译时更改。主流的CMake、GNU Autoconf等工具都是支持这种方式的。这也是GNU推荐的方式。为了克服不够灵活的问题,很多程序还允许用户通过命令行参数等方式来重新指定配置文件的位置。

优点:稳定

缺点:不够灵活

我们目前的做法

基本上我们目前用的时CMake来在编译时确定配置文件的绝对路径,但是这个路径直接指向源码树中的配置文件。。有些奇怪,但在进入部署阶段前,这种做法应该都还是挺好用的。


返回文章列表

评论

登录 / 注册 后发布评论