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?

  • 1
    Are you using source control? Are the resources under source control as well?
    – Doc Brown
    Aug 20, 2015 at 20:17
  • 1
    I think that a great and simple solution would be taking an argument like --resources-root=/path/to/resources with some reasonable default value.
    – cubuspl42
    Aug 20, 2015 at 21:56
  • @DocBrown Yes the resources are also under source control; does that help me?
    – user695652
    Aug 22, 2015 at 4:32
  • Well, if you use, for example, SVN, there is the "externals" feature which can help you to get a copy of your resource files always at the right place, somewhere below your checkout directory, even when it is not part of the source tree of your the program you are working with. In other source control systems you can "emulate" such a feature by scripts.
    – Doc Brown
    Aug 22, 2015 at 5:54

1 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.