[Boost-build] Paths, Target OS & configurations

Subject: [Boost-build] Paths, Target OS & configurations
From: mareq (mq_at_[hidden])
Date: 2012-09-04 18:37:02

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?

--
View this message in context: http://boost.2283326.n4.nabble.com/Paths-Target-OS-configurations-tp4635258.html
Sent from the Boost - Build mailing list archive at Nabble.com.