How to deal with relative paths in out of source build?

Question

An out of source build is a build which can be in any directory other than the source directory

---

I have a project which contains relative paths to some resource files, needed at runtime, which are located close to the source directory.

But when I build the project in an arbitrary folder, the resource files are (obviously) not found.

What is the proper way of providing paths to resource files?

Answer 1

I assume that your program is coded in a compiled language (that is a language implemented in a compiler) like C or C++ or Ocaml, and that your operating system is Linux (or perhaps some other POSIX compliant OS).

First, you could embed resources inside your executable. For that, you would compile a large constant byte array (à la XBM), e.g. in C const char resbytes[] = { ... some very long sequence of bytes, e.g. 23, 97, etc... }; . That source file could obviously be generated by some shell script (perhaps with the help of hexdump(1), etc...)

Then, you could decides that resources are installed at some fixed (or compile-time configurable) path, outside of the build tree. This is the case for most GNU software (like gcc, bash, emacs, make etc...), see the directory variables of the GNU coding standard. Your installation step (e.g. make install) would copy these files at some appropriate places, e.g. under /usr/share/ or /usr/lib/ etc..... And the places would be built inside the installed executable (you might have them under /usr/share/resources/myprog/ and pass -DRESOURCEDIR="/usr/share/resources/myprog/" to your g++ compilation command, using relevant make tricks). You might find autoconf helpful.

Notice that resources are needed (to be accessible) for the installed executable, not for the build tree.

Alternatively, at least on Linux, you could decide that resources are installed at some relative place w.r.t. the program executable (.e.g. in some grand-parent directory); IIRC this is the case for xemacs. Then, the issue is to find out the path of the executable and its directory (to later append a relative subpath, like "../lib/fonts/" etc..., to it). On Linux you just have to readlink(2) the "/proc/self/exe" symlink (and use dirname(3) on the result). On many other POSIX systems you could probably use the argv[0] of main and probably getenv("PATH") to find and compute it (perhaps with the later help of realpath(3)...).

Some framework libraries (like Qt or POCO or perhaps GTK or its Glib) might have conventions about resources and functions supporting them.

An example of a complex free software needing resources is the GCC compiler and it has to be built outside the source tree. You might look inside it to get inspired by its "resource management" (notably compiler predefined headers à la <limits.h> or <stdarg.h>...)

For Linux, look also into the Filesystem Hierarchy Standard and hier(7) which defines useful conventions.