Step-by-step how-to needed for two modularised Boost use cases
Denis Arnaud
I'm updating a small C program to take in a options from either
environment variables, or a config file and having long heard of boost
as a great resource decided to give the program_options module a try.
Since the utility is small and I don't have any current plans for
other boost functionality it doesn't make sense to include the full
BOOST library, so I tried to use bcp to get only the files I'm
interested in. I was able to get a subset of boost code that I should
be able to use with bcp, however I don't know how to compile the
program_options library for linking in my code.
>From a bit of googling it looks like bjam is the build tool, but it
doesn't seem to be included with the subset of files I have.
How would I go about incorporating boost so that all of the necessary
source and associated utilities are included for an end user to build
from. I should be able to issue a series of simple commands (looks
like ./bootstrap.sh and make) to build and install my library with
statically linked in boost.
-Will Voorhees
I believe that is a perfect (use) case for the current Ryppl's modularised Boost initiative.
By the way, I'd like to use a Boost component still in the sandbox, namely ECDF Accumulator:
https://svn.boost.org/svn/boost/sandbox/acc_ecdf/
Daniel Pfeifer
> the program_options component stand-alone:
> Boost initiative.
program_options using the following commands:
git clone git://github.com/ryppl/rypplite.git
git clone git://github.com/boost-lib/program_options.git
mkdir build
cd build
cmake -DBoost_DIR=/absolute/path/to/rypplite ../program_options
make
You will get an error message saying that quickbook cannot be found. I
will fix this error tonight.
My main issue is the list of dependencies. It currently pulls the
following modules: algorithm bind config detail filesystem functional
integer lambda mpl parameter property_map python regex static_assert
timer typeof utility any circular_buffer conversion disjoint_sets
foreach function_types io logic multi_index phoenix property_tree
random serialization system tokenizer type_traits uuid array cmake
core dynamic_bitset format fusion iostreams math numeric pool proto
range smart_ptr test tr1 units variant assign concept_check date_time
exception function graph iterator mpi optional preprocessor
ptr_container rational spirit thread tuple unordered xpressive
> By the way, I'd like to use a Boost component still in the sandbox, namely
> ECDF Accumulator:https://svn.boost.org/svn/boost/sandbox/acc_ecdf/
>
> Could you give me a way to do that thanks to the modularised Boost
> framework?
its header files into 'boost/accumulators/statistics/ecdf' but the
'boost/accumulators' directory might be a symlink pointing into the
source directory of Boost.Accumulators.
This whole header forwarding stuff seems to do more harm than good.
As I remember, the initial goal of the forwarding headers was to keep
the number of parameters passed to the compiler at a minimum. But is
the command length actually a problem? Otherwise it maybe would be a
good idea to get rid of the forwarding headers entirely. Then every
module will use the include directories it really needs and won't be
able to accidentally include headers of a library that is not listed
as a dependency. This would also make the test results more
meaningful.
Once we have a better solution concerning the headers, I will show you
how to use acc_ecdf.
cheers, Daniel
Dave Abrahams
Daniel Pfeifer wrote:
>
> This whole header forwarding stuff seems to do more harm than good.
> As I remember, the initial goal of the forwarding headers was to keep
> the number of parameters passed to the compiler at a minimum. But is
> the command length actually a problem?
Unfortunately, on Windows, yes, it can be. There is an arbitrarily
low limit to the length of command lines that go through the CMD
processor.
Most Windows compilers therefore support "response files:" the ability
to write command-line parameters into a file and then instead specify
just that file on the command-line using "@<filename>.rsp". It
appears that CMake supports response files, but some compilers
tartgeting Windows (most notably those based on GCC) didn't, the last
time I checked.
You can of course invoke programs without going through CMD, but I
don't know whether any of the windows build drivers (make, nmake,
vcbuild, etc.) have that capability. I suppose one possibility would
be to create thin compiler wrappers as part of the build process and
then invoke those. These wrappers would process .rsp files and then
invoke the underlying tools directly (without going through the shell)
> Otherwise it maybe would be a good idea to get rid of the forwarding
> headers entirely. Then every module will use the include directories
> it really needs and won't be able to accidentally include headers of
> a library that is not listed as a dependency. This would also make
> the test results more meaningful.
That would be extremely valuable.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com