I need to use few (hardcored) paths in my application (e.g. path to data directory). The problem is that these paths are dependent on:
- target OS (including e.g. Linux distribution: e.g. Debian vs. Red Hat)
- user's preferences (--prefix, but also --bindir, --datadir, etc. options)
I would like to make Boost.Build to #define preprocessor macros for all these paths and then use these macros in my sources. In fact, this is easy, thus so far so good. But: when I compile half of the project (e.g. some error occurred in the middle of compilation) with one configuration (e.g. --prefix=/usr/local) and the other half with different configuration (e.g. --prefix=/usr), whole application will be obviously broken. The same applies also to compilation with one set of configuration properties and installation (bjam -q install) with yet different configuration.
Therefore, it seems that it is necessary to save user's preferences as well as target OS and all the stuff to some persistent storage (some configuration file?) and then use it throughout whole compilation & installation process. Once that configuration changes, whole project needs to be recompiled from scratch.
At first glance, it seemed ok to "encode" these preferences into Boost.Build's build directory hierarchy (build/release/gcc-4.6/target-os-linux/prefix-foo/bindir-bar/... etc.). But since there is quite a few options available (bindir, libexecdir, datadir, localedir, sysconfigdir, runtimedir, logfiledir - i.e. 7 possibly long paths just for starters), this solution does not seem ideal anymore. Also, in order to achieve such functionality, custom features must be created and used instead of command line arguments, for each of these options. This complicates matters even more (e.g. how to provide installation rule, which will obey these custom features?). It becomes even more complicated, when one starts to think about validation (e.g. it should not be possible to request --prefix=/usr/local for <target-os>windows, because such path is invalid on Windows OS).
I was looking at package.jam (and some other modules shipped with Boost.Build), but it does not really solve the problem.
Is there some straightforward way how to solve this kind of problems I simply do not see, or is it really (nearly) impossible to solve all of the above described problems and meet such requirements? How would you approach such problem?