Re: [Boost-users] A plea for simpler tools

Subject: Re: [Boost-users] A plea for simpler tools
From: John Maddock (boost.regex_at_[hidden])
Date: 2012-02-14 04:05:55

> a) create a directory structure outside of the boost tree which looks 
> like:
>
> mylib
>  build
>  include
>  src
>  doc
>    html
>    docbook(maybe)
>    boostbook(maybe)
>    quickbook(maybe)
>  test
>    results
>        ...
>
> b) a set of simple tools which
>  1) can build the library in the src directory
>  2) can translate quick/boost/doc book to html and place it in that 
> directory
>  3) run each test in the test directory and add a record to the 
> test/results/... log file which I will either just lookat or post process 
> locally to my personal taste.
>
> c) what I don't need
>  1) tracking dependencies - I want to do this for on library I might be 
> experimenting with. I can do this by hand.
>  2) I don't need to have my boost tree updated - in fact I want to know 
> that I haven't changed it by just running a simple tool
>
> d) current tools:
>  1) presume that a library is part of the boost directory structure.  So 
> the documents show up somewhere in the boost tree.  Note when I build the 
> documents on my local boost release image I get pointers to the boost 
> sandbox or on sourceforge.net or whatever.  So for boostbook->html would 
> like to be able to say boostbook2html -in <boostbookdir> -out 
> <htmldirectory> or something simple like this.
>  2) the only way I've found to use the current tools is to create 
> directories in my local boost release tree with my "experimental" library 
> and run bjam.  There are two problems with this
>    i) I have to make a jamfile which might be more complicated that first 
> meets the eye
>    ii) I mucks up my boost release tree.
>   iii) it I get something wrong, it fails deep within some bjam script 
> which is extremely difficult to figure out.
>    iv) For an example to iii) above, I had tweaked userconfig.v2 to 
> include the name of my xsltproc program which was found through the path. 
> Later I elimnated the directory of the xsltproc from my path. Later I 
> found I couldn't build my library or run any tests.  Turned out that bjam 
> stopped when it failed to find the xsltproc program - even though it 
> wasn't being used.  I'm not critisizing bjam.  I think it's impossible to 
> make a program as ambituous as this totally perfect.  But I question the 
> need for such an elaborate tool for doing what seems to me should be 
> something simple.
>
> Of course, I can do this myself - and likely will end up doing so.  But:
>
> a) I've got other stuff to do
> b) I can't believe I'm the only one who needs this
> c) I think that boost tools are "too automatic" for my purposes.  I 
> understand the motivation for building all of boost.  But for what I want 
> to do  it adds a huge layer of "conceptual overhead" that I have to wade 
> through.
>
> Before I invest effort in this perhaps there's a way of using existing 
> tools that I'm not aware that get's me closer to what I want and need.

For sure - take a look at the "example" project in the sandbox - it should 
do more or less all that you want - you just need BOOST_ROOT set in your 
environment to point to an existing Boost tree so that bjam commands will 
"work".

HTH, John.