A plea for simpler tools
Let me start by saying I love Boost and C++ as much or more than anyone here!!! But I'm really frustrated with the boost tools and believe they are a serious impediment to the progress of boost. Here is what I want to be able to do: 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. Comments welcome. Robert Ramey
On 2/13/2012 2:20 PM, Robert Ramey wrote:
Let me start by saying I love Boost and C++ as much or more than anyone here!!!
Let ME start by saying I appreciate you staying as involved with Boost as you have been. Authors disappearing is Boost's biggest problem (IMHO) and you haven't.
But I'm really frustrated with the boost tools and believe they are a serious impediment to the progress of boost. Here is what I want to be able to do: [...]
A "bjam Cookbook" would be very useful. Working examples that accomplish reasonably simple things. We mere mortals look at parts of boost that frustrate us and blame ourselves for not "getting it." It's good to hear we're not alone. (I realize that many give up too quickly, too.) I don't want this to be a bjam pile-on, either -- what it does for the regression tests is very impressive. But sometimes it feels that if bjam strays off a well-worn path, you can get a big, bad, intimidating stack-dump through scads of platform-specific files, whose contents you can neither understand nor verify. I know there was a Boost.CMake effort a while back, probably motivated by just what you wrote. That would be fine, too.
Jim Bell wrote:
On 2/13/2012 2:20 PM, Robert Ramey wrote:
Let me start by saying I love Boost and C++ as much or more than anyone here!!!
Let ME start by saying I appreciate you staying as involved with Boost as you have been. Authors disappearing is Boost's biggest problem (IMHO) and you haven't.
NOTE - TL;DR This is way off topic - but I would like to respond anyway. The above might be true, I haven't noticed that much. I suppose that it might because that if I use a component and it works - I don't notice. If I try to use something and it turns into a problem, I just set it aside and move on to another solution (usually). I have a low tolerance for frustration (I'm getting older - it get's worse). So I don't think I notice it that much. As for my own motivation. My first motivation was was that I wanted to learn C++ to a lot better than I knew it before. This I accomplished. By that time, I managed to do that, I had writting the serialization library. The first versions had some bugs and it offended my self image to permit them to stay unfixed. I have a big ego. So what you suggest as a professional commitment is likely a manifestation of a personality flaw. oh well. (Even the current version has a few design flaws - I've left track items which highlight them, but for now ...). After I got things working to my satisfaction, there is very little work to do actually. Just once in a while I respond to the user list. It's very easy for me to do and it provides sort of a "comic relief". To me, if you're library (or application) requires a lot of maintainence it's not done yet. If people require lot's of hand holding to get it work or understand how to use it, it's a bug - either in the code, design, or documentation. The three things have to be considered as a whole. Which brings me to my current effort - which is to update my original artcle - "Making a Boost Library" to include observations gathered over several years of developing and maintaining hte library. Part of is to make a simple small library and show how to get it preparied so that it has a chance of getting in to boost without turning the process into a death march. This is in turn motivated by my concern that Boost/C++ needs a little "boost" to make it to the next level where it needs to be now that most of the "simple" libraries are done. Even microsoft is now acknowledged that C++ is the future - prepare for a bumpy ride!!!! So I want to make the process smoother. Also off topic - considering people who have hung in there are a few who deserve really special mention. Dave Abrahams, Beamon Dawes, John Maddock - I"m sure there are others whose libraries I depend upon every day. And special mention should go to Vladimir Prus. I know I complain about bjam all the time but where would boost be without it? And Vladimir is ALWAYS available when required - over many years. I see no conflict at all in complaining about bjam and holding Vladimir in the highest esteem both as a person and a professional. (Hmm my wife complains about me all the time but I think she loves me - oh well). Robert Ramey
On 13 February 2012 20:20, Robert Ramey <ramey@rrsd.com> wrote:
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.
Boost Build is meant to work without the boost tree. If you've used the bootstrap install it should install all the necessary boost build files along with the executable. I just tried creating a simple "hello world" example. In an empty directory I created a 'hello.cpp' file, with this in Jamroot.jam: exe hello : hello.cpp ; And that worked fine (well, I had to comment out my 'using bookbook' line, for similar reasons that you did with 'using xsltproc'). Just remember that there needs to be a Jamroot.jam in the root directory, so that boost build can know where the root of the tree is. Depending on boost is a little more complicated. Take a look at: http://svn.boost.org/svn/boost/sandbox/example/ If you've set the BOOST_ROOT environment variables to the location of your boost tree, it should be possible to build it separately from boost. In the root is a Jamroot.jam file which will use boost located at $BOOST_ROOT. If the BOOST_BUILD_PATH logic was removed, it could be simpler: path-constant top : . ; import modules ; import path ; local boost-root = [ modules.peek : BOOST_ROOT ] ; if ! $(boost-root) { ECHO "Error: BOOST_ROOT not set" ; exit ; } path-constant BOOST_ROOT : $(boost-root) ;
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.
Maybe toolsets like xsltproc and boostbook should check for files lazily (i.e. only when they're actually used). Possibly with a command line option to get boost build to check all of the toolsets mentioned in configuration jamfiles. Strictly speaking, default 'using xsltproc' or 'using boostbook' directives wouldn't be required if all documentation Jamfiles contained the appropriate 'using' directives. But most people don't realise this. It'd be nice if it was an error if they're missing, or just a warning at least, but I don't think that's easy to do.
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.
participants (4)
-
Daniel James -
Jim Bell -
John Maddock -
Robert Ramey