英文:

Preferred Method Of Accessing Data File From Linux Shared Library

问题

I am attempting to build an open source program into a library to be installed on my machine. It is basically a math library for some physics simulations. I want to be able to link against it as if it were any ordinary distribution library. I have done this thing before and try to do it in a more or less proper way, so that I don't have random files in my directories owned by root. By this I mean I build the shared library in the manner specified here and package them and install the package using the distribution package manager (Pacman).

The software I want to install now includes data files used in the calculations (basically coefficients for a series). The sample program that is sent just reads those coefficients in the current directory, and that path could be modified in the source file. But my question is, after installation the path will be somewhere like '/usr/local/lib/' which will depend on how I install this data file. To note, I always install my own programs, libraries, and headers under '/usr/local/' as would be appropriate.

This seems like a bit of a silly question to me, but is there any preferred way to define the path where that data file will be? I'm thinking there must be a clean way to do this because some libraries come with their own directories with additional executables and data files. For example, the Xorg library is at '/usr/lib/Xorg' and there is also a directory '/usr/lib/xorg/' with a file '/usr/lib/xorg/protocols.txt' that looks to me like it is probably used for something. Obviously, the Xorg developers are not actually developing in '/usr/lib/' so there should be some simple variable that can be set. Also, while for X it would be weird, for other libraries it is possible it could be installed under '/usr/local/' rather than '/usr/' directly. This is why I am trying to do this, fundamentally if I like how this works I should be able to submit it to the distribution as a candidate package but then it should not be under 'local' in that case.

I can always embed the data into the program as strings or something like that, I just wanted to see if I could figure out the right way to do this, where the program could be updated to new coefficients without a recompilation. Please let me know if this is not clear.

英文:

I am attempting to build an open source program into a library to be installed on my machine. It is basically a math library for some physics simulations. I want to be able to link against it as if it were any ordinary distribution library. I have done this thing before and try to do it in a more or less proper way, so that I don't have random files in my directories owned by root. By this I mean I build the shared library in the manner specified here and package them and install the package using the distribution package manager (Pacman).

The software I want to install now includes data files used in the calculations (basically coefficients for a series). The sample program that is sent just reads those coefficients in the current directory, and that path could be modified in the source file. But my question is, after installation the path will be somewhere like '/usr/local/lib/' which will depend on how I install this data file. To note, I always install my own programs, libraries, and headers under '/usr/local/' as would be appropriate.

This seems like a bit of a silly question to me, but is there any preferred way to define the path where that data file will be? I'm thinking there must be a clean way to do this because some libraries come with their own directories with additional executables and data files. For example, the Xorg library is at '/usr/lib/Xorg' and there is also a directory '/usr/lib/xorg/' with a file '/usr/lib/xorg/protocols.txt' that looks to me like it is probably used for something. Obviously, the Xorg developers are not actually developing in '/usr/lib/' so there should be some simple variable that can be set. Also, while for X it would be weird, for other libraries it is possible it could be installed under '/usr/local/' rather than '/usr/' directly. This is why I am trying to do this, fundamentally if I like how this works I should be able to submit it to the distribution as a candidate package but then it should not be under 'local' in that case.

I can always embed the data into the program as strings or something like that, I just wanted to see if I could figure out the right way to do this, where the program could be updated to new coefficients without a recompilation. Please let me know if this is not clear.

答案1

得分: 0

在这一点上，我能够识别的最弹性的方法是类似于：

```c
#ifndef INSTALLATION_PREFIX
#define INSTALLATION_PREFIX "./"
#endif

#define DATA_FILE_NAME "datafile.txt"

const char * datafilefullpath = INSTALLATION_PREFIX DATA_FILE_NAME;

FILE * datafile = fopen(datafilefullpath, "r");

INSTALLATION_PREFIX 宏可以设置为构建的配置参数。这允许在开发期间构建在源目录中（或其某个子目录中，如 "./build" 或其他任何目录），也可以构建到各种最终系统安装位置，如 "/usr/lib/"、"/usr/local/lib" 或其他任何位置。显然，这些信息可以在构建脚本的其他地方使用，例如在 "make install" 配方中。

请注意，我在 C 编译器级别上使用了字符串的拼接。

<details>
<summary>英文:</summary>

At this point, the most resilient method I can identify is something along the lines of:

#ifndef INSTALLATION_PREFIX
#define INSTALLATION_PREFIX "./"
#endif

#define DATA_FILE_NAME = "datafile.txt"

const char * datafilefullpath = INSTALLATION_PREFIX DATA_FILE_NAME;

FILE * datafile = fopen(datafilefullpath, "r");

The `INSTALLATION_PREFIX` macro can be set as a configuration parameter to the build. This allows for building in the source directory (or some sub directory of it such as "./build" or whatever) during development and also building for various final system installation locations, such as "/usr/lib/" or "/usr/local/lib" or anything else. Obviously, this information could be used elsewhere in the build script, like in the `make install` recipe.

Note that I am using the concatenation of juxtaposed strings at the C compiler level here.

I will leave this question open a day or two to see if anyone else has a better answer. Otherwise, I will accept my own.

</details>