Re: [boost] Re: Boost to the rescue
----- Mensaje original ----- De: Robert Ramey <ramey@rrsd.com> Fecha: Viernes, Abril 15, 2005 6:05 pm Asunto: [boost] Re: Boost to the rescue
I'm amazed to discover that in only ONE single case have any of the programmers, managers, etc ever even heard of boost. This group even includes an ex head of the computer science department at a top tier university !!!
Speaking of which, I've got the nasty feeling that a good portion of the C++ programming community have heard of Boost but don't use it because: 1. It's too big. 2. It's too hard to install. 3. The docs are too technical. 4. They fear it's too "advanced" for them to understand it. I've actually read comments on programmer sites touching on every one of these issues. My opinion is that: * #1 is not that much of an issue in a world where people are happy to install a multimegabyte IDE and don't complain about it. When it comes to installing a library, somehow they measure size by a different standard. * #2 is certainly a point, specially for Windows folks used to doubleclick on everything. Maybe it'd be a good idea to produce some graphical wizards (not necessarily as an official part of Boost) that automate the installation for at least the most commonly used platforms (read MS.) IMHO this would lower the entry barrier a lot. * As for #3 and #4, I've got this idea round my head that Boost would benefit of a "community site" where people of various expertise levels could mingle together, post Boost-related articles, etc. Something like CodeProject or Gamedev, which have a less intimidating appearance than www.boost.org. Some months ago I asked for a Boost-related forum in CodeProject, to no avail :( Well, just some random ideas. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
"JOAQUIN LOPEZ MU?Z" wrote:
Speaking of which, I've got the nasty feeling that a good portion of the C++ programming community have heard of Boost but don't use it because:
1. It's too big.
I heard this too. IOW they fear dependencies. It would be useful to paint "this is not framework, you may use just small piece" everywhere. The bcp should be "marketed" better, not many know about it.
* As for #3 and #4, I've got this idea round my head that Boost would benefit of a "community site" where people of various expertise levels could mingle together, post Boost-related articles, etc. Something like CodeProject or Gamedev, which have a less intimidating appearance than www.boost.org. Some months ago I asked for a Boost-related forum in CodeProject, to no avail :(
Something ala CP would help both users and aspiring library writers. CP doesn't want more page-views? /Pavel
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of JOAQUIN LOPEZ MU?Z | Sent: 15 April 2005 18:45 | To: boost@lists.boost.org | Subject: Re: [boost] Re: Boost to the rescue | | | | ----- Mensaje original ----- Speaking of which, I've got the nasty feeling that | a good portion of the C++ programming community have | heard of Boost but don't use it because: | | 1. It's too big. | 2. It's too hard to install. | 3. The docs are too technical. | 4. They fear it's too "advanced" for them to understand it. | I have also heard several comments like this too. I would suggest that the documentation should stress that most of the Boost code is header only, and that one only need to add the location of the unpacked code to the include path to get access to tons of really useful stuff. Grappling with new tools, like bjam (useful and essential as they may be) is a real turn off. We need to get people started. Only when they are hooked will they be prepared to invest in the effort to build the invaluable regex and the like. And documentation MUST have TONS of EXAMPLES. This is where most people start. Without examples, they never start. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com
"Paul A Bristow" <pbristow@hetp.u-net.com> writes:
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of JOAQUIN LOPEZ MU?Z | Sent: 15 April 2005 18:45 | To: boost@lists.boost.org | Subject: Re: [boost] Re: Boost to the rescue | | | | ----- Mensaje original ----- Speaking of which, I've got the nasty feeling that | a good portion of the C++ programming community have | heard of Boost but don't use it because: | | 1. It's too big. | 2. It's too hard to install. | 3. The docs are too technical. | 4. They fear it's too "advanced" for them to understand it. | I have also heard several comments like this too.
I would suggest that the documentation should stress that most of the Boost code is header only,
I'm not sure we should make too much of that. I don't know how long that will remain the case, and anyway it may not matter to the person who's really interested in Boost.Python or Serialization or Threads, or Regex, or...
and that one only need to add the location of the unpacked code to the include path to get access to tons of really useful stuff.
Well, as long as you put it that way, maybe there's something to it.
Grappling with new tools, like bjam (useful and essential as they may be) is a real turn off.
Yeah, well we need to make that easier and more accessible.
We need to get people started.
Yep.
Only when they are hooked will they be prepared to invest in the effort to build the invaluable regex and the like.
Yep.
And documentation MUST have TONS of EXAMPLES.
Yep.
This is where most people start. Without examples, they never start.
Someone at ACCU suggested that we have a "libraries overview page" that contains a short introduction and a mini-tutorial example for each of the libraries. I think it's a great idea and would vastly increase accessibility of the libraries. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Wed, 27 Apr 2005 17:09:56 -0400, David Abrahams wrote
Someone at ACCU suggested that we have a "libraries overview page" that contains a short introduction and a mini-tutorial example for each of the libraries. I think it's a great idea and would vastly increase accessibility of the libraries.
Good idea, but what does it mean in practical fact? It would be a hugely long page to have a tutorial of all the libraries. Just putting the library list no longer fits on a single page. We already have libraries by category. Several years ago I had the idea that a graphical view of the library categories might be a nice way to navigate among the libraries. My little prototype is still on the wiki (each category is a hyperlink to the category on the libs by category page). http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostUserFAQ Now I can imagine we could do other things like bring up lists of the libraries in a category, etc. Is it better than a simple text list? I personally like it better, but it certainly never caught on. Another idea is to make get the library documentation links immediately available from the front page. Make the front page 3 columns and have all the libraries or at least the categories listed on the left column... Yet another idea would be to have a single page library teaser, including code example, linked available from the library list. So a few sentences of intro text and some code examples as a really fast intro that people could scan to get the gist of the library in action. Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Wed, 27 Apr 2005 17:09:56 -0400, David Abrahams wrote
Someone at ACCU suggested that we have a "libraries overview page" that contains a short introduction and a mini-tutorial example for each of the libraries. I think it's a great idea and would vastly increase accessibility of the libraries.
Good idea, but what does it mean in practical fact? It would be a hugely long page to have a tutorial of all the libraries.
Make that a micro-tutorial then. It's supposed to be just enough to get an idea.
Just putting the library list no longer fits on a single page. We already have libraries by category.
Yep. It would be long.
Several years ago I had the idea that a graphical view of the library categories might be a nice way to navigate among the libraries. My little prototype is still on the wiki (each category is a hyperlink to the category on the libs by category page).
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostUserFAQ
Doesn't work for me. IMO the graphics add nothing. Why not just a table if you like grids?
Now I can imagine we could do other things like bring up lists of the libraries in a category, etc. Is it better than a simple text list? I personally like it better, but it certainly never caught on.
Another idea is to make get the library documentation links immediately available from the front page. Make the front page 3 columns and have all the libraries or at least the categories listed on the left column...
That sounds like a good idea, but of course it addresses a different need.
Yet another idea would be to have a single page library teaser, including code example, linked available from the library list. So a few sentences of intro text and some code examples as a really fast intro that people could scan to get the gist of the library in action.
That is in the same ballpark as what I suggested. However, having to click through to the material will make it harder for a user to get an overall picture of what's in Boost. -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Wed, 27 Apr 2005 17:09:56 -0400, David Abrahams wrote
Someone at ACCU suggested that we have a "libraries overview page" that contains a short introduction and a mini-tutorial example for each of the libraries. I think it's a great idea and would vastly increase accessibility of the libraries.
Good idea, but what does it mean in practical fact? It would be a hugely long page to have a tutorial of all the libraries.
Make that a micro-tutorial then. It's supposed to be just enough to get an idea.
Just putting the library list no longer fits on a single page. We already have libraries by category.
Yep. It would be long.
It will only get longer and that makes it harder to find what's really interesting on each occasion you visit that page.
Several years ago I had the idea that a graphical view of the library categories might be a nice way to navigate among the libraries. My little prototype is still on the wiki (each category is a hyperlink to the category on the libs by category page).
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostUserFAQ
Doesn't work for me. IMO the graphics add nothing. Why not just a table if you like grids?
What about organizing the main libraries page by group (<H1>) with a TOC of those groups. Then, in each group, create a secondary TOC listing each library. For each library, provide a link to the overview, its main documentation, its code in CVS, and its Wiki page, if any. (If you get to the point of providing a download for each library, that could be listed as well.) With so many links, it can get confusing, but I'm thinking of the following, which could be graphically represented using icons: <H1>Template Metaprogramming</H1> <B>mpl - Template metaprogramming framework of compile-time algorithms, sequences and metafunction classes</B> [Overview] [Docs] [Code] [Wiki] <B>static_assert - Static assertions (compile time assertions)</B> [Overview] [Docs] [Code] [Wiki] <B>type_traits - Templates for fundamental properties of types</B> [Overview] [Docs] [Code] [Wiki] BTW, there can be a link near the top to an alphabetical list of libraries, too, since that is often just what you need. That list can contain the same link structure shown above (which suggests generating it from the same source).
Another idea is to make get the library documentation links immediately available from the front page. Make the front page 3 columns and have all the libraries or at least the categories listed on the left column...
That sounds like a good idea, but of course it addresses a different need.
That would make the front page awfully busy.
Yet another idea would be to have a single page library teaser, including code example, linked available from the library list. So a few sentences of intro text and some code examples as a really fast intro that people could scan to get the gist of the library in action.
That is in the same ballpark as what I suggested. However, having to click through to the material will make it harder for a user to get an overall picture of what's in Boost.
I don't think many users would read through one big page of such teasers, though. Maybe an all-encompassing example that uses most of the libraries would work. IOW, the example could build from a simple idea to a full program that uses most libraries with a brief mention of why each exists and how it would apply to the example. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
On Wed, 27 Apr 2005 17:09:56 -0400, David Abrahams wrote
Someone at ACCU suggested that we have a "libraries overview page" that contains a short introduction and a mini-tutorial example for each of the libraries. I think it's a great idea and would vastly increase accessibility of the libraries.
Good idea, but what does it mean in practical fact? It would be a hugely long page to have a tutorial of all the libraries.
Make that a micro-tutorial then. It's supposed to be just enough to get an idea.
Just putting the library list no longer fits on a single page. We already have libraries by category.
Yep. It would be long.
It will only get longer and that makes it harder to find what's really interesting on each occasion you visit that page.
The particular page being proposed isn't about "finding what's really interesting." It's more like a magazine about Boost and its capabilities that you can browse through to get familiar with what's there.
Yet another idea would be to have a single page library teaser, including code example, linked available from the library list. So a few sentences of intro text and some code examples as a really fast intro that people could scan to get the gist of the library in action.
That is in the same ballpark as what I suggested. However, having to click through to the material will make it harder for a user to get an overall picture of what's in Boost.
I don't think many users would read through one big page of such teasers, though.
No they wouldn't; they'd skip over the ones that were clearly of no interest. The page down key works nicely.
Maybe an all-encompassing example that uses most of the libraries would work.
NooooooooooO. Please, no! That would introduce all kinds of interactions and complexity. The idea is to give people an easy way to find out "what each library does."
IOW, the example could build from a simple idea to a full program that uses most libraries with a brief mention of why each exists and how it would apply to the example.
To understand that you have to read through the whole thing. That defeats the purpose. -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
Make that a micro-tutorial then. It's supposed to be just enough to get an idea.
Just putting the library list no longer fits on a single page. We already have libraries by category.
Yep. It would be long.
It will only get longer and that makes it harder to find what's really interesting on each occasion you visit that page.
The particular page being proposed isn't about "finding what's really interesting." It's more like a magazine about Boost and its capabilities that you can browse through to get familiar with what's there.
I think you mistook my meaning. I meant that folks would revisit the page periodically to learn about libraries they didn't pay attention to previously. I may also have misunderstood the page you envision, but it sounds to me like a really long page with library after library of text and example code, with one mostly just running into the next. If you meant there would be a TOC with links to each library and especially if you meant there would be some sort of grouping, then it will probably work reasonably.
Yet another idea would be to have a single page library teaser, including code example, linked available from the library list. So a few sentences of intro text and some code examples as a really fast intro that people could scan to get the gist of the library in action.
That is in the same ballpark as what I suggested. However, having to click through to the material will make it harder for a user to get an overall picture of what's in Boost.
Tabbed browsing makes that palatable, even useful.
I don't think many users would read through one big page of such teasers, though.
No they wouldn't; they'd skip over the ones that were clearly of no interest. The page down key works nicely.
It works nicely until you get tired of paging past uninteresting parts.
Maybe an all-encompassing example that uses most of the libraries would work.
NooooooooooO. Please, no! That would introduce all kinds of interactions and complexity. The idea is to give people an easy way to find out "what each library does."
OK. OK. It was just an idea to make it possible to show synergy among the libraries and to give a glimpse of what each can do.
IOW, the example could build from a simple idea to a full program that uses most libraries with a brief mention of why each exists and how it would apply to the example.
To understand that you have to read through the whole thing. That defeats the purpose.
As I saw it, that example would make for interesting -- even compelling -- reading and would give incentive to keep reading to learn about all of the libraries. Also as I saw it, yours was a longer read without cohesiveness. Now I think you just mean to provide a small example with a little explanatory text with each listed library rather than the one-liner now present. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
From: David Abrahams <dave@boost-consulting.com>
"Jeff Garland" <jeff@crystalclearsoftware.com> writes:
Make that a micro-tutorial then. It's supposed to be just enough to get an idea.
Just putting the library list no longer fits on a single page. We already have libraries by category.
Yep. It would be long.
It will only get longer and that makes it harder to find what's really interesting on each occasion you visit that page.
The particular page being proposed isn't about "finding what's really interesting." It's more like a magazine about Boost and its capabilities that you can browse through to get familiar with what's there.
I think you mistook my meaning. I meant that folks would revisit the page periodically to learn about libraries they didn't pay attention to previously.
You obviously need a different page for that; one that's sorted by recent-ness.
I may also have misunderstood the page you envision, but it sounds to me like a really long page with library after library of text and example code, with one mostly just running into the next.
Yes one long page, but, I think we'd use dividers or major headings to separate them.
If you meant there would be a TOC with links to each library
Well of course a TOC would be helpful.
and especially if you meant there would be some sort of grouping, then it will probably work reasonably.
Those are minor details. The main idea is to have a brief overview of what's available, but not so brief that you have to go look at individual library docs just to have a sense of how it's used.
Yet another idea would be to have a single page library teaser, including code example, linked available from the library list. So a few sentences of intro text and some code examples as a really fast intro that people could scan to get the gist of the library in action.
That is in the same ballpark as what I suggested. However, having to click through to the material will make it harder for a user to get an overall picture of what's in Boost.
Tabbed browsing makes that palatable, even useful.
I don't see how that is related.
I don't think many users would read through one big page of such teasers, though.
No they wouldn't; they'd skip over the ones that were clearly of no interest. The page down key works nicely.
It works nicely until you get tired of paging past uninteresting parts.
If you're paging past most of what's there, then you wanted something that the page wasn't designed to do in the first place.
Maybe an all-encompassing example that uses most of the libraries would work.
NooooooooooO. Please, no! That would introduce all kinds of interactions and complexity. The idea is to give people an easy way to find out "what each library does."
OK. OK. It was just an idea to make it possible to show synergy among the libraries and to give a glimpse of what each can do.
KISS.
IOW, the example could build from a simple idea to a full program that uses most libraries with a brief mention of why each exists and how it would apply to the example.
To understand that you have to read through the whole thing. That defeats the purpose.
As I saw it, that example would make for interesting -- even compelling -- reading and would give incentive to keep reading to learn about all of the libraries. Also as I saw it, yours was a longer read without cohesiveness. Now I think you just mean to provide a small example with a little explanatory text with each listed library
Yes.
rather than the one-liner now present.
No, it's not meant to be a replacement for the existing library index. -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
I think you mistook my meaning. I meant that folks would revisit the page periodically to learn about libraries they didn't pay attention to previously.
You obviously need a different page for that; one that's sorted by recent-ness.
OK.
I may also have misunderstood the page you envision, but it sounds to me like a really long page with library after library of text and example code, with one mostly just running into the next.
Yes one long page, but, I think we'd use dividers or major headings to separate them. [snip] Those are minor details. The main idea is to have a brief overview of what's available, but not so brief that you have to go look at individual library docs just to have a sense of how it's used.
OK.
Tabbed browsing makes that palatable, even useful.
I don't see how that is related.
You scan the list, Ctrl-click (or whatever) on each library that looks interesting, as you're scanning, so each loads its teaser page in a tab. Finally, you visit each tab to read the teaser.
It works nicely until you get tired of paging past uninteresting parts.
If you're paging past most of what's there, then you wanted something that the page wasn't designed to do in the first place.
I didn't realize the page had been designed already. I thought that was the point of this discussion.
Maybe an all-encompassing example that uses most of the libraries would work.
NooooooooooO. Please, no! That would introduce all kinds of interactions and complexity. The idea is to give people an easy way to find out "what each library does."
OK. OK. It was just an idea to make it possible to show synergy among the libraries and to give a glimpse of what each can do.
KISS.
Who are you calling stupid! ;-)
As I saw it, that example would make for interesting -- even compelling -- reading and would give incentive to keep reading to learn about all of the libraries. Also as I saw it, yours was a longer read without cohesiveness. Now I think you just mean to provide a small example with a little explanatory text with each listed library
Yes.
rather than the one-liner now present.
No, it's not meant to be a replacement for the existing library index.
Obviously I missed something which could have told me that the page under discussion was a new page and what its design and purpose were. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
Obviously I missed something which could have told me that the page under discussion was a new page and what its design and purpose were.
``Someone at ACCU suggested that we have a "libraries overview page" that contains a short introduction and a mini-tutorial example for each of the libraries. I think it's a great idea and would vastly increase accessibility of the libraries.'' -- Dave Abrahams Boost Consulting www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
Obviously I missed something which could have told me that the page under discussion was a new page and what its design and purpose were.
``Someone at ACCU suggested that we have a "libraries overview page" that contains a short introduction and a mini-tutorial example for each of the libraries. I think it's a great idea and would vastly increase accessibility of the libraries.''
OK, I read that, but I didn't take it as requiring the creation of a new page (versus replacing the existing page) and I didn't see it as implying some of the other aspects you took as intrinsic. Regardless, I understand your view on those matters. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
On 4/15/05, JOAQUIN LOPEZ MU?Z <joaquin@tid.es> wrote:
Speaking of which, I've got the nasty feeling that a good portion of the C++ programming community have heard of Boost but don't use it because:
1. It's too big. 2. It's too hard to install.
I can see a point in #1; but "big" not only in terms of megabytes, but also in terms of sheer number of libraries and functionality. Many people will rather reinvent the few wheels they need rather than getting a car with 50 wheels (i.e. Boost). However, from my experience, as soon as you use one Boost library, you're kind of hooked: you'll look at Boost for any new library you need. I find installing Boost is pretty easy; but as long as one hasn't tried it yet, Boost may look scarily big. There has been talk before on something like "Boost Light". Combining concerns #1 and #2, wouldn't it be a good idea to supply a small subset of boost consisting of header-only libraries only? Regards, Rogier
"Rogier van Dalen" <rogiervd@gmail.com> wrote
I find installing Boost is pretty easy; but as long as one hasn't tried it yet, Boost may look scarily big.
There has been talk before
on something like "Boost Light". Combining concerns #1 and #2, wouldn't it be a good idea to supply a small subset of boost consisting of header-only libraries only?
I would have thought a system such as r.p.m / windows installer could be used. Is the requirement not just a remote version of the functionality of bcp ?. Tie this in to the http://www.boost.org/libs/libraries.htm with a suitable installer and it would certainly attract casual users. Perhaps this represents dumbing down ? regards Andy Little
"Rogier van Dalen" <rogiervd@gmail.com> wrote
on something like "Boost Light". Combining concerns #1 and #2, wouldn't it be a good idea to supply a small subset of boost consisting of header-only libraries only?
I would have thought a system such as r.p.m / windows installer could be used.
well if you run RedHat Fedora Linux distro you get the boost rpms automatically :) That is, I might have selected them somehow earlier, I don't remember; if I use the yum tool to list installed packages I get: [root@frodo ~]# yum list boost Setting up Repos base 100% |=========================| 1.1 kB 00:00 updates-released 100% |=========================| 951 B 00:00 Reading repository metadata in from local files base : ################################################## 2622/2622 primary.xml.gz 100% |=========================| 340 kB 00:02 MD Read : ################################################## 855/855 updates-re: ################################################## 855/855 Installed Packages boost.i386 1.32.0-1.fc3 installed Available Packages boost.i386 1.32.0-5.fc3 updates-released This tells me that I already had boost.i386 1.32.0-1.fc3 installed installed, and that I could update to boost.i386 1.32.0-5.fc3 updates-released I tried: d [root@frodo ~]# [root@frodo ~]# yum update boost Setting up Update Process Setting up Repos base 100% |=========================| 1.1 kB 00:00 updates-released 100% |=========================| 951 B 00:00 Reading repository metadata in from local files base : ################################################## 2622/2622 updates-re: ################################################## 855/855 Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for boost to pack into transaction set. boost-1.32.0-5.fc3.i386.r 100% |=========================| 8.3 kB 00:00 ---> Package boost.i386 0:1.32.0-5.fc3 set to be updated --> Running transaction check Dependencies Resolved Transaction Listing: Update: boost.i386 0:1.32.0-5.fc3 - updates-released Total download size: 589 k Is this ok [y/N]: y Downloading Packages: (1/1): boost-1.32.0-5.fc3 100% |=========================| 589 kB 00:04 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating: boost 100 % done 1/2 Completing update for boost - 2/2 Updated: boost.i386 0:1.32.0-5.fc3 Complete! [root@frodo ~]# was simple as typing:
yum update boost
My conclusion, at least on some Linux distros it is not too hard to get boost installed :) I see no reson it should not be this easy on other platforms. But getting it installed is not quite the same as getting people to use it. Bjørn Roald
"Bjørn Roald" <bjorn@4roald.org> wrote
well if you run RedHat Fedora Linux distro you get the boost rpms automatically :)
I was thinking more in terms of a finer grained system, whereby each library in the boost distro comprised a separately installable package r.p.m has has the right sort of functionality . Unfortunately I think it has the wrong type of licence. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
well if you run RedHat Fedora Linux distro you get the boost rpms automatically :)
I was thinking more in terms of a finer grained system, whereby each library in the boost distro comprised a separately installable package r.p.m has has the right sort of functionality . Unfortunately I think it has the wrong type of licence.
I do not understand this concern. Any installer-builder I know can be used as long as the developer has licence to use it. AFAIK tools for building rpms are free to use on Linux. On other platforms somebody with the right lisenced tools may need to build the installers, then they can be distributed from the boost web-site. This is kind-of-like using gcc or vc++ for generating libs from your own source. The output is your property. I think there are a lot of good installers out there, some are even multi-platform. Like bjam :) -- some may be easier to use, but "easy" here, depends on the perspective of the user. Windows users typically expect something that feels like InstallShield; nothing prevents having bjam hidden behind something that looks like a normal installer. TrollTech does that when their windows installer builds Qt on windows using their makefile generator called "qmake". I think building boost against the compiler on the installation machine is a good thing. The problem is not to get boost installed, the problem is to make developers realize the benefits of using it, and to avoid scaring them off in the process. I agree that a clumsy installation procedure may scare some potential users off, but to be honest I do not think that is the biggest obstacle for potential new boost users. My experience installing boost the first time was quite pleasant even if I had to learn a few things about a tool called bjam and get it installed first. I later learned that it came as rpms, but I have never tried to use boost as installed from the rpm. For users used to tools like yum, rpms are very easy to install if they are available. So what are the real obstacles: 1. Managers acceptance of introducing a new tool 2. Convincing other developers on your team 3. Lack of consistant documentation 4. Lack of consistant support of all platforms (to me Sun CC support has been a problem) 5. Lack of a good measure of the stability of the API of various boost libraries I feel like no. 5 is a real concern the boost team could do something about with little effort. You do not feel secure that the next version of boost will support your code, thus you feel like it may be risky to stick your neck out. Some clear statements of which libraries was considdered to be stable would be very nice. regards, Bjørn Roald
Bjørn Roald <bjorn@4roald.org> wrote:
The problem is not to get boost installed, the problem is to make developers realize the benefits of using it, and to avoid scaring them off in the process. I agree that a clumsy installation procedure may scare some potential users off, but to be honest I do not think that is the biggest obstacle for potential new boost users.
My experience installing boost the first time was quite pleasant even if I had to learn a few things about a tool called bjam and get it installed first.
My view is very different from yours. The last thing that I want to do when I am installing a new program is learn about a new build system. On Unix, the install procedure should really be "configure ; make ; make install". There is really no excuse for that not to be the case. I would expect a binary installer on Windows. In fact, there should be a list of binary packages on the front page. If they don't exist for a platform (OS X?), they need to be built and offered there. Regards, Walter Landry wlandry@ucsd.edu
"Walter Landry" <wlandry@ucsd.edu> wrote
The problem is not to get boost installed, the problem is to make developers realize the benefits of using it, and to avoid scaring them off in the process. I agree that a clumsy installation procedure may scare some potential users off, but to be honest I do not think that is the biggest obstacle for potential new boost users.
My experience installing boost the first time was quite pleasant even if I had to learn a few things about a tool called bjam and get it installed first.
My view is very different from yours. The last thing that I want to do when I am installing a new program is learn about a new build system. On Unix, the install procedure should really be "configure ; make ; make install". There is really no excuse for that not to be the case. I would expect a binary installer on Windows. In fact, there should be a list of binary packages on the front page. If they don't exist for a platform (OS X?), they need to be built and offered there.
I do agree with what you write, I do not think our wievs are that different on the installers, I was just pointing out that for me bjam worked fine and that I do not think installation is biggest hurdle to jump for potential users. I may be wrong. However on Linux people expect both the configure, make, make install and the packages for their distro. I guess developers should be happy with building. configure -- could do what configure does, option for installation root other than /usr/local make -- could build bjam and call it to build boost make install -- could install by calling the appropriate command in bjam Does not seem to hard to pull this off, I for one would not have considdered using autoconfig and friends on all of boost when you have boost jam unless there are platforms bjam will not support. But I do not considder myself an expert on this. One concern I have
Walter Landry wrote:
Bjørn Roald <bjorn@4roald.org> wrote:
My experience installing boost the first time was quite pleasant even if I had to learn a few things about a tool called bjam and get it installed first.
My view is very different from yours. The last thing that I want to do when I am installing a new program is learn about a new build system. On Unix, the install procedure should really be "configure ; make ; make install". There is really no excuse for that not to be the case.
Here are some reasons, none of them are excuses, why it's not "configure; make install".. 1. Nobody has volunteered the time and expertise to support such a system. 2. Such a system would be unusable to Boost developers which have to work with a variety of compilers and systems, usually at the same time. Hence it would be a user only UI; so there is less incentive to support something like autoconf. 3. Other than historical familiarity, one of the UI intuitive factors, it's doesn't give users any improvements on functionality or ease of use than the current: "bjam install". If people are willing to devote some effort we'd welcome what I would consider the optimal solution of just: "install". Which would use a system similar to the Linux Kernel configurator of providing a UI, graphical or curses, to select parts to install, to build, and to install.
I would expect a binary installer on Windows.
Same as above.. I would welcome someone building a GUI that supports fine grained selection of libraries, and tools to install and compilers to install for. For example I use this.. On Windows. http://www.jrsoftware.org/isinfo.php Inno Setup -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera <grafik.list@redshift-software.com> wrote:
Walter Landry wrote:
Bjørn Roald <bjorn@4roald.org> wrote:
My experience installing boost the first time was quite pleasant even if I had to learn a few things about a tool called bjam and get it installed first.
My view is very different from yours. The last thing that I want to do when I am installing a new program is learn about a new build system. On Unix, the install procedure should really be "configure ; make ; make install". There is really no excuse for that not to be the case.
Here are some reasons, none of them are excuses, why it's not "configure; make install"..
1. Nobody has volunteered the time and expertise to support such a system.
You must have missed the enormous flamewars when people suggested using autoconf. For example http://lists.boost.org/MailArchives/boost/msg25583.php Given the response, I am not surprised that there is no autoconf support in Boost.
2. Such a system would be unusable to Boost developers which have to work with a variety of compilers and systems, usually at the same time. Hence it would be a user only UI; so there is less incentive to support something like autoconf.
You are confusing me. The whole point of autoconf is to deal with a variety of compilers and systems.
3. Other than historical familiarity, one of the UI intuitive factors,
Don't knock it.
it's doesn't give users any improvements on functionality or ease of use than the current: "bjam install".
Except that you don't have to install bjam. It would also have a chance of working properly. On my system, bjam could not find the development headers for my python install, and it spits out annoying warning if I use a new version of gcc. This is a bit ridiculous.
If people are willing to devote some effort we'd welcome what I would consider the optimal solution of just: "install". Which would use a system similar to the Linux Kernel configurator of providing a UI, graphical or curses, to select parts to install, to build, and to install.
I don't need that much. Just "configure; make; make install". Cheers, Walter Landry wlandry@ucsd.edu
Walter Landry wrote:
Rene Rivera <grafik.list@redshift-software.com> wrote:
1. Nobody has volunteered the time and expertise to support such a system.
You must have missed the enormous flamewars when people suggested using autoconf. For example
No I didn't didn't miss it. And if you had read that thread you would have seen my replies in that thread for example: http://article.gmane.org/gmane.comp.lib.boost.devel/63354
Given the response, I am not surprised that there is no autoconf support in Boost.
Is that "not surprised" because of my response or the thread you referenced?
2. Such a system would be unusable to Boost developers which have to work with a variety of compilers and systems, usually at the same time. Hence it would be a user only UI; so there is less incentive to support something like autoconf.
You are confusing me. The whole point of autoconf is to deal with a variety of compilers and systems.
Autoconf is about dealing with *one* compiler and *one* system. Boost developers often switch between compilers, and sometimes compile for multiple compilers at the same time. That is something that is cumbersome to do with autoconf.
3. Other than historical familiarity, one of the UI intuitive factors,
Don't knock it.
I wasn't.. But it's a weak reason to pick between two alternatives ;-)
it's doesn't give users any improvements on functionality or ease of use than the current: "bjam install".
Except that you don't have to install bjam.
Only because autoconf is already installed on most system. That is something that is becoming true for bjam as well.
It would also have a chance of working properly. On my system, bjam could not find the development headers for my python install,
You mean Boost.Build could not find the headers.
and it spits out annoying warning if I use a new version of gcc.
Which has nothing to do with Boost.Build or bjam. But with Boost.Config. -- Just clarifying.. not criticizing :-)
This is a bit ridiculous.
If people are willing to devote some effort we'd welcome what I would consider the optimal solution of just: "install". Which would use a system similar to the Linux Kernel configurator of providing a UI, graphical or curses, to select parts to install, to build, and to install.
I don't need that much. Just "configure; make; make install".
For that we could just shell scripts at the boost root with: ----configure--- #!/bin/sh ----configure--- ----make--- #!/bin/sh p=${PWD} cd tools/build/jam_src export LOCATE_TARGET=bin sh ./build.sh cd ${p} ./tools/build/jam_src/bin/bjam "$@" ---make--- :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
On Mon, 18 Apr 2005, Rene Rivera wrote:
Walter Landry wrote:
Rene Rivera <grafik.list@redshift-software.com> wrote:
1. Nobody has volunteered the time and expertise to support such a system.
You must have missed the enormous flamewars when people suggested using autoconf. For example
No I didn't didn't miss it. And if you had read that thread you would have seen my replies in that thread for example:
http://article.gmane.org/gmane.comp.lib.boost.devel/63354
Given the response, I am not surprised that there is no autoconf support in Boost.
Is that "not surprised" because of my response or the thread you referenced?
2. Such a system would be unusable to Boost developers which have to work with a variety of compilers and systems, usually at the same time. Hence it would be a user only UI; so there is less incentive to support something like autoconf.
You are confusing me. The whole point of autoconf is to deal with a variety of compilers and systems.
Autoconf is about dealing with *one* compiler and *one* system. Boost developers often switch between compilers, and sometimes compile for multiple compilers at the same time. That is something that is cumbersome to do with autoconf.
Having always used autoconf for my projects, I don't really find having multiple build roots cumbersome, and use separate build roots for every package that I build, and every project that I work on: tar xjvf package-0.0.tar.bz2 mkdir build-PLATFORM cd build-PLATFORM ../package-0.0/configure <options> make make install With bjam I found things a bit more difficult. Once I downloaded and built bjam, to build boost I first made a shell script: #!/bin/sh -x bjam --prefix=/dept/rnd/importlibs/LINUX_IA32/suse9.2/boost-1.32.0-gcc400pre1 \ --builddir=build-SUSE_IA32-gcc400pre1 --with-python-root=/usr \ -sPYTHON_VERSION=2.3 -sGCC=/dept/rnd/vendor/gcc-4.0.0-20050410/bin/gcc \ -sGXX=/dept/rnd/vendor/gcc-4.0.0-20050410/bin/g++ --layout=system $* and use that shell script to build from the toplevel directory. Figuring out all the settings to use a different compiler and python version took a bit of work the first time, but I just chalked that up to inexperience with bjam. Whenever I needed to build boost for another platform, I'd just copy that script, change the variables and rebuild. The part where I ran into difficulty was when I tried to build the python testsuite as I was trying test the python docstring handling fixes. I couldn't figure out what the right target was to build it from the root, and trying to build in the python test directory I discovered that the -- options were only supported in the toplevel jamfile, and I ended up having to read through the jamfile to find out what the -- options mapped onto in terms of bjam settings, modify the script to use those settings instead and then call the script from the test directory, and also set the BOOST_ROOT variable. Again, it could just be inexperience and perhaps there's an easier way, but if there is it's not documented well. With autoconf, once you run configure, everything autoconf auto-detects and everything you specify is baked into the Makefiles (and your configure line logged to config.status) in your build root, and in the case above, all I would have had to do is: cd libs/python/test; make Other things that I'm sure are there with bjam but that I haven't had time to figure out: * parallel building e.g. make -j [number] * build a particular directory e.g. make -C <directory> * stopping at the first error bjam by default seems to do the equivalent of make -k * making bjam feel/be faster It takes about 15 seconds on my box for bjam just to gather the target list, before it even tries to update any targets. With my gcc build, a full traverse of all the directories takes about two seconds. I know it's not apples to apples, as boost undoubtedly has a greater of header dependencies to check, but if we're just looking at targets that get built there's 985 files that were built in my boost build directory and 1228 in my gcc build directory. I'm sure all my problems with bjam are just unfamiliarity, and I'm also sure that bjam has benefits over a make-based system that I don't see, but on the whole all I really care about as far as build systems go is unobtrusiveness. In that regard, autoconf based systems are the winner for me due to their familiarity, consistency and pervasiveness. -nick
nick@ilm.com (Nick Rasmussen) writes:
On Mon, 18 Apr 2005, Rene Rivera wrote:
Walter Landry wrote:
You are confusing me. The whole point of autoconf is to deal with a variety of compilers and systems.
Autoconf is about dealing with *one* compiler and *one* system. Boost developers often switch between compilers, and sometimes compile for multiple compilers at the same time. That is something that is cumbersome to do with autoconf.
Having always used autoconf for my projects, I don't really find having multiple build roots cumbersome, and use separate build roots for every package that I build, and every project that I work on:
How did "multiple build roots" come into this?
tar xjvf package-0.0.tar.bz2 mkdir build-PLATFORM cd build-PLATFORM ../package-0.0/configure <options> make make install
With bjam I found things a bit more difficult. Once I downloaded and built bjam, to build boost I first made a shell script:
#!/bin/sh -x bjam --prefix=/dept/rnd/importlibs/LINUX_IA32/suse9.2/boost-1.32.0-gcc400pre1 \ --builddir=build-SUSE_IA32-gcc400pre1 --with-python-root=/usr \ -sPYTHON_VERSION=2.3 -sGCC=/dept/rnd/vendor/gcc-4.0.0-20050410/bin/gcc \ -sGXX=/dept/rnd/vendor/gcc-4.0.0-20050410/bin/g++ --layout=system $*
I agree that's too hard.
and use that shell script to build from the toplevel directory. Figuring out all the settings to use a different compiler and python version took a bit of work the first time, but I just chalked that up to inexperience with bjam. Whenever I needed to build boost for another platform, I'd just copy that script, change the variables and rebuild.
The part where I ran into difficulty was when I tried to build the python testsuite as I was trying test the python docstring handling fixes. I couldn't figure out what the right target was to build it from the root, and trying to build in the python test directory I discovered that the -- options were only supported in the toplevel jamfile, and I ended up having to read through the jamfile to find out what the -- options mapped onto in terms of bjam settings,
That's because in BBv1 the -- options are a hack used to make things easy for people installing from the top layer. BBv2 should make this pain go away.
With autoconf, once you run configure, everything autoconf auto-detects and everything you specify is baked into the Makefiles (and your configure line logged to config.status) in your build root, and in the case above, all I would have had to do is:
cd libs/python/test; make
Yes. Autoconf is a lot better for the build-to-install user. For the multi-platform/multi-compiler developer it's not so great.
Other things that I'm sure are there with bjam but that I haven't had time to figure out:
* parallel building e.g. make -j [number]
bjam -j [number]
* build a particular directory e.g. make -C <directory>
cd <directory> && bjam
* stopping at the first error bjam by default seems to do the equivalent of make -k
I think that's correct. I don't think there's an option for that one.
* making bjam feel/be faster It takes about 15 seconds on my box for bjam just to gather the target list, before it even tries to update any targets. With my gcc build, a full traverse of all the directories takes about two seconds. I know it's not apples to apples, as boost undoubtedly has a greater of header dependencies to check,
It's not the header dependencies that slow it down. BBv2 is much faster than BBv1.
but if we're just looking at targets that get built there's 985 files that were built in my boost build directory and 1228 in my gcc build directory.
I'm sure all my problems with bjam are just unfamiliarity,
No, not even most of them.
and I'm also sure that bjam has benefits over a make-based system that I don't see, but on the whole all I really care about as far as build systems go is unobtrusiveness. In that regard, autoconf based systems are the winner for me due to their familiarity, consistency and pervasiveness.
They work great on Unix for certain kinds of jobs. They don't work so well on Windows. They're better for users and worse for developers that don't know how to write autoconf internals. I think we can make Boost.Build easier to learn and use than autoconf is, but I have to admit that it's not a hands-down win yet. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
nick@ilm.com (Nick Rasmussen) writes:
On Mon, 18 Apr 2005, Rene Rivera wrote:
Walter Landry wrote:
You are confusing me. The whole point of autoconf is to deal with a variety of compilers and systems.
Autoconf is about dealing with *one* compiler and *one* system. Boost developers often switch between compilers, and sometimes compile for multiple compilers at the same time. That is something that is cumbersome to do with autoconf.
Having always used autoconf for my projects, I don't really find having multiple build roots cumbersome, and use separate build roots for every package that I build, and every project that I work on:
How did "multiple build roots" come into this?
I think he was referring to doing multiple different directories where you do a "configure" with different settings of compiler, and other settings. Which is the way you work with more than one compiler and autoconf.
tar xjvf package-0.0.tar.bz2 mkdir build-PLATFORM cd build-PLATFORM ../package-0.0/configure <options> make make install
With bjam I found things a bit more difficult. Once I downloaded and built bjam, to build boost I first made a shell script:
#!/bin/sh -x bjam --prefix=/dept/rnd/importlibs/LINUX_IA32/suse9.2/boost-1.32.0-gcc400pre1 \ --builddir=build-SUSE_IA32-gcc400pre1 --with-python-root=/usr \ -sPYTHON_VERSION=2.3 -sGCC=/dept/rnd/vendor/gcc-4.0.0-20050410/bin/gcc \ -sGXX=/dept/rnd/vendor/gcc-4.0.0-20050410/bin/g++ --layout=system $*
I agree that's too hard.
But it's not any harder than the *real* autoconf equivalent of: tar xjvf package-0.0.tar.bz2 mkdir build-SUSE_IA32-gcc400pre1 cd build-SUSE_IA32-gcc400pre1 export PYTHON_VERSION=2.3 export PYTHON_ROOT=/usr ###-haven't seen a configure script you can change which ###-python should be used export GCC=/dept/rnd/vendor/gcc-4.0.0-20050410/bin/gcc export GXX=/dept/rnd/vendor/gcc-4.0.0-20050410/bin/g++ ../package-0.0/configure --prefix=/dept/rnd/importlibs/LINUX_IA32/suse9.2/boost-1.32.0-gcc400pre1 make make install And I dare people to point more than one configure script, or configure installation instructions that tell you that you can set GCC/CC etc. to use something other than the system compiler.
discovered that the -- options were only supported in the toplevel jamfile, and I ended up having to read through the jamfile to find out what the -- options mapped onto in terms of bjam settings,
That's because in BBv1 the -- options are a hack used to make things easy for people installing from the top layer. BBv2 should make this pain go away.
Well it will eventually.. I only recently convinced Volodya that having those top level options everywhere was a good idea. And, yes in BBv1 this is a hack :-)
* stopping at the first error bjam by default seems to do the equivalent of make -k
I think that's correct. I don't think there's an option for that one.
bjam -q Although I haven't tried it, so don't know if it works.
and I'm also sure that bjam has benefits over a make-based system that I don't see, but on the whole all I really care about as far as build systems go is unobtrusiveness. In that regard, autoconf based systems are the winner for me due to their familiarity, consistency and pervasiveness.
They work great on Unix for certain kinds of jobs. They don't work so well on Windows. They're better for users and worse for developers that don't know how to write autoconf internals. I think we can make Boost.Build easier to learn and use than autoconf is, but I have to admit that it's not a hands-down win yet.
Here's a test for you to see how close we are to being there.. With the latest Boost CVS state, make your user-config.jam have only this (which will eventually be done by default): import msvc-config ; import cw-config ; import pythong-config ; And cd to boost-root and do: bjam --v2 --with-thread install And that's it. Which only leaves the install of bjam itself, but we can work on that also. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
On Wed, 27 Apr 2005, Rene Rivera wrote:
tar xjvf package-0.0.tar.bz2 mkdir build-PLATFORM cd build-PLATFORM ../package-0.0/configure <options> make make install
With bjam I found things a bit more difficult. Once I downloaded and built bjam, to build boost I first made a shell script:
#!/bin/sh -x bjam --prefix=/dept/rnd/importlibs/LINUX_IA32/suse9.2/boost-1.32.0-gcc400pre1 \ --builddir=build-SUSE_IA32-gcc400pre1 --with-python-root=/usr \ -sPYTHON_VERSION=2.3 -sGCC=/dept/rnd/vendor/gcc-4.0.0-20050410/bin/gcc \ -sGXX=/dept/rnd/vendor/gcc-4.0.0-20050410/bin/g++ --layout=system $*
I agree that's too hard.
But it's not any harder than the *real* autoconf equivalent of:
tar xjvf package-0.0.tar.bz2 mkdir build-SUSE_IA32-gcc400pre1 cd build-SUSE_IA32-gcc400pre1
export PYTHON_VERSION=2.3 export PYTHON_ROOT=/usr ###-haven't seen a configure script you can change which ###-python should be used
these would probably be a --with option, not environment variables.
export GCC=/dept/rnd/vendor/gcc-4.0.0-20050410/bin/gcc export GXX=/dept/rnd/vendor/gcc-4.0.0-20050410/bin/g++ ../package-0.0/configure --prefix=/dept/rnd/importlibs/LINUX_IA32/suse9.2/boost-1.32.0-gcc400pre1 make make install
And I dare people to point more than one configure script, or configure installation instructions that tell you that you can set GCC/CC etc. to use something other than the system compiler.
The AC_PROG_CC and AC_PROG_CXX print this out by default now at the bottom of the configure --help output. e.g.: Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a nonstandard directory <lib dir> CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have headers in a nonstandard directory <include dir> CPP C preprocessor CXX C++ compiler command CXXFLAGS C++ compiler flags CXXCPP C++ preprocessor Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations. The one thing you're missing that makes bjam a lot more complex than autoconf is that you have to specify all your options for every invocation of bjam, where as once you configure a particular build root with an autoconf setup, all that information is baked into the generated Makefiles. After I configure there's no requirement to have any particular environment variables set or arguments passed to make. -nick
Nick Rasmussen wrote:
The AC_PROG_CC and AC_PROG_CXX print this out by default now at the bottom of the configure --help output. e.g.:
Some influential environment variables: CC C compiler command CFLAGS C compiler flags LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a nonstandard directory <lib dir> CPPFLAGS C/C++ preprocessor flags, e.g. -I<include dir> if you have headers in a nonstandard directory <include dir> CPP C preprocessor CXX C++ compiler command CXXFLAGS C++ compiler flags CXXCPP C++ preprocessor
Use these variables to override the choices made by `configure' or to help it to find libraries and programs with nonstandard names/locations.
Cool.. At least they are making progress :-) Just like we are trying to ;-)
The one thing you're missing that makes bjam a lot more complex than autoconf is that you have to specify all your options for every invocation of bjam, where as once you configure a particular build root with an autoconf setup, all that information is baked into the generated Makefiles. After I configure there's no requirement to have any particular environment variables set or arguments passed to make.
Correct.. And I think that's the point you originally wanted to make. But that's a much better way of making it ;-) So from your point of view, and obviously others, it would be good to have a "bjam [options..] configure" that would create a default set of options for you. And from that point onward you could just do "bjam .." and it would use those defaults. Of course it would still be possible to override at any time, and to set another default. I think that would be possible with BBv2 and some work. There's no way BBv1 can be twisted into doing something like that. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera <grafik.list@redshift-software.com> wrote:
Walter Landry wrote:
Rene Rivera <grafik.list@redshift-software.com> wrote:
1. Nobody has volunteered the time and expertise to support such a system.
You must have missed the enormous flamewars when people suggested using autoconf. For example
No I didn't didn't miss it. And if you had read that thread you would have seen my replies in that thread for example:
http://article.gmane.org/gmane.comp.lib.boost.devel/63354
Given the response, I am not surprised that there is no autoconf support in Boost.
Is that "not surprised" because of my response or the thread you referenced?
Because of the general hostility shown towards autoconf in that thread (and this one). It certainly does not motivate me to work on an autoconf'ing boost. Even so, I just realized that there is some support for autoconf in boost (in libs/config), but it is incomplete. <snip>
If people are willing to devote some effort we'd welcome what I would consider the optimal solution of just: "install". Which would use a system similar to the Linux Kernel configurator of providing a UI, graphical or curses, to select parts to install, to build, and to install.
I don't need that much. Just "configure; make; make install".
For that we could just shell scripts at the boost root with:
This doesn't do any configuration. You need the configure step to run libs/config/configure and copy user.hpp to the right place. You also need configure to handle things like PYTHON_ROOT. Finally, it doesn't handle install. If you work out all of those things, then I will be happy. Cheers, Walter Landry wlandry@ucsd.edu
Walter Landry wrote:
Because of the general hostility shown towards autoconf in that thread (and this one). It certainly does not motivate me to work on an autoconf'ing boost. Even so, I just realized that there is some support for autoconf in boost (in libs/config), but it is incomplete.
Hi, Walter. Just for information, I see that there are already some boost macros available in the autoconf macros repository at http://autoconf-archive.cryp.to/macros-by-category.html ax_boost_date-time ax_boost_filesystem ax_boost_python ax_boost_regex ax_boost_signals ax_boost_thread Regards, Angus
Walter Landry wrote:
it's doesn't give users any improvements on functionality or ease of use than the current: "bjam install".
Except that you don't have to install bjam.
You don't have to install bjam, actually. Just tools/build/jam_src/build.sh && tools/build/jam_src/bin.linuxx86/bjam -sTOOLS=gcc install would work on Linux. And as Rene pointed out, this can be placed into file called "Makefile".
It would also have a chance of working properly. On my system, bjam could not find the development headers for my python install,
Do you know stock autoconf macro which finds Python headers? If not, then the task of writing one is just as hard as writing this logic in Python's jamfile.
and it spits out annoying warning if I use a new version of gcc. This is a bit ridiculous.
It's a bit strange that you try to blame bjam for everything. This warning is produced by boost.config headers, for no good reason (IMO).
If people are willing to devote some effort we'd welcome what I would consider the optimal solution of just: "install". Which would use a system similar to the Linux Kernel configurator of providing a UI, graphical or curses, to select parts to install, to build, and to install.
I don't need that much. Just "configure; make; make install".
Then solution like Rene's will work fine. It's not clear that we've arrived at the point where real configure system is better than current config.hpp. And if we've arrived, I'd much rather use Python-based system. Say, SCons has such module, which does no depend on SCons and can be adapted to Boost.Build. - Volodya
Vladimir Prus writes:
Do you know stock autoconf macro which finds Python headers?
Peter Simons wrote:
Vladimir Prus writes:
Do you know stock autoconf macro which finds Python headers?
Sorry, but it does not work. After lots of errors, I see this output: results of the Python check: Binary: python2.3 Library: python2.3 Include Dir: /home/ghost/windows/cygwin2/usr/include/python2.3 Clearly, the path is as wrong as possibly could be. And the macros does not allow to specify the version of Python that I want. This is certainly fixable, but requires autoconf/M4 knowledge, so autoconf does not yet looks like a silver bullet. And if we need any configure system, it's better written in Python. - Volodya
Vladimir Prus writes:
Sorry, but it does not work.
How about this one? http://autoconf-archive.cryp.to/az_python.html And just in case ... http://autoconf-archive.cryp.to/ac_python_devel.html http://autoconf-archive.cryp.to/ax_python_config_var.html Yes, there are plenty of Python macros in the autoconf archive. ;-) Peter
At Monday 2005-04-18 05:44, you wrote:
Rene Rivera <grafik.list@redshift-software.com> wrote:
Walter Landry wrote:
Bjørn Roald <bjorn@4roald.org> wrote:
My experience installing boost the first time was quite pleasant even if I had to learn a few things about a tool called bjam and get it installed first.
My view is very different from yours. The last thing that I want to do when I am installing a new program is learn about a new build system. On Unix, the install procedure should really be "configure ; make ; make install". There is really no excuse for that not to be the case.
Here are some reasons, none of them are excuses, why it's not "configure; make install"..
1. Nobody has volunteered the time and expertise to support such a system.
You must have missed the enormous flamewars when people suggested using autoconf. For example
http://lists.boost.org/MailArchives/boost/msg25583.php
Given the response, I am not surprised that there is no autoconf support in Boost.
2. Such a system would be unusable to Boost developers which have to work with a variety of compilers and systems, usually at the same time. Hence it would be a user only UI; so there is less incentive to support something like autoconf.
You are confusing me. The whole point of autoconf is to deal with a variety of compilers and systems.
does it work on Windows? and the book on autoconf / automake is the least scrutable book ever written in the English language.
3. Other than historical familiarity, one of the UI intuitive factors,
Don't knock it.
it's doesn't give users any improvements on functionality or ease of use than the current: "bjam install".
Except that you don't have to install bjam.
or install autoconf
It would also have a chance of working properly. On my system, bjam could not find the development headers for my python install, and it spits out annoying warning if I use a new version of gcc. This is a bit ridiculous.
on my system autoconf results in: T:\boost\include\boost-1_32\boost>autoconf 'autoconf' is not recognized as an internal or external command, operable program or batch file. and the last time I -did- have it installed, it got run 5 times by an install script and tested the same damned stuff over and over and over. IMO a worthless piece of junk.
If people are willing to devote some effort we'd welcome what I would consider the optimal solution of just: "install". Which would use a system similar to the Linux Kernel configurator of providing a UI, graphical or curses, to select parts to install, to build, and to install.
I don't need that much. Just "configure; make; make install".
as I said, "configure" don't exist on my systems, and like it or not, *nix is a _very_ small portion of the market.
Cheers, Walter Landry wlandry@ucsd.edu
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
On Mon, Apr 18, 2005 at 10:48:20AM -0700, Victor A. Wagner Jr. wrote:
Except that you don't have to install bjam.
or install autoconf
You only need to install autoconf if you want to generate configre scripts, not if you want to use them. Think of it as a JamFile generator, except the output is a script. Users have to install bjam to install boost - that is not the case with autoconf, only the developers need autoconf, which they use to prepare a script that the users will use. To quote from the autoconf RPM description on my system: Note that the Autoconf package is not required for the end-user who may be configuring software with an Autoconf-generated script; Autoconf is only required for the generation of the scripts, not their use. Conversely, end-users *are* required to build or install bjam to make use of the JamFiles that come with Boost.
It would also have a chance of working properly. On my system, bjam could not find the development headers for my python install, and it spits out annoying warning if I use a new version of gcc. This is a bit ridiculous.
on my system autoconf results in: T:\boost\include\boost-1_32\boost>autoconf 'autoconf' is not recognized as an internal or external command, operable program or batch file.
and the last time I -did- have it installed, it got run 5 times by an install script and tested the same damned stuff over and over and over. IMO a worthless piece of junk.
Are you sure? Are you that what was running wasn't a configure script? (probably generated by autoconf, yes, but not running autoconf)
If people are willing to devote some effort we'd welcome what I would consider the optimal solution of just: "install". Which would use a system similar to the Linux Kernel configurator of providing a UI, graphical or curses, to select parts to install, to build, and to install.
I don't need that much. Just "configure; make; make install".
as I said, "configure" don't exist on my systems, and like it or not, *nix is a _very_ small portion of the market.
Each package comes with its own "configure" script that does what it needs to, you don't have a single "configure" that lives on your system. Once you've built and installed the software you can delete the configure script, along with the rest of the sources. I'm not arguing that Boost should switch, as I have no experience of using on non-unix platforms, but I do find bjam less scrutable than I'd like. More important than changing how the Boost libs are built and installed (which is something you do at most once per system, per release) is pkgconfig support to make it easier to use an installed Boost. You use the installed headers and libs far more frequently than you install them. jon
Hi, I do not have time to read through this thread completely, but here couple notes: 1. There is no sense IMO comparing bjam with autoconfig. It's apples and oranges. bjam is make substitution. The only advantage of make is that it's already present in most systems. We chose bjam over make for reasons (look into bjam docs for some them) that included better flexibility, portability and expression power. 2. Boost..Build could be considered as a counterpart to autoconfig. These two follow different ideology: Boost.Build present precreated configuration files (tools definition) while autoconfig allows to generate these from some source pattern based on system characteristics. I personally prefer preexistent files if it possible. 3. I personally don't see what this "installation fuss" is all about. in majority of the cases the whole installation is: "pkzip -d boost.zip" or similar. Providers of "packages" could do whatever they want and add build steps. This is a bit oversimplification. but I do not see need for better installation (whatever this means) as a showstopper in any form. Regards, Gennadiy
"Jonathan Wakely" <cow@compsoc.man.ac.uk> schrieb im Newsbeitrag news:20050418185419.GB78458@compsoc.man.ac.uk...
On Mon, Apr 18, 2005 at 10:48:20AM -0700, Victor A. Wagner Jr. wrote:
Except that you don't have to install bjam.
or install autoconf
You only need to install autoconf if you want to generate configre scripts, not if you want to use them. Think of it as a JamFile generator, except the output is a script.
The Win32 shell (cmd.exe/command.com) can run autoconf generated scripts? Bertolt
On Tue, Apr 19, 2005 at 06:52:32AM +0200, Bertolt Mildner wrote:
"Jonathan Wakely" <cow@compsoc.man.ac.uk> schrieb im Newsbeitrag news:20050418185419.GB78458@compsoc.man.ac.uk...
On Mon, Apr 18, 2005 at 10:48:20AM -0700, Victor A. Wagner Jr. wrote:
Except that you don't have to install bjam.
or install autoconf
You only need to install autoconf if you want to generate configre scripts, not if you want to use them. Think of it as a JamFile generator, except the output is a script.
The Win32 shell (cmd.exe/command.com) can run autoconf generated scripts?
I don't know, but I doubt it. You probably need a unix shell. But you still don't need to have autoconf installed. Again, I'm *not* arguing in favour of using autotools instead of bjam, I was just clarifying some misconceptions about autoconf, since discussing its virtues/sins is difficult when it's being misrepresented. jon
Walter Landry <wlandry@ucsd.edu> writes:
You must have missed the enormous flamewars when people suggested using autoconf. For example
http://lists.boost.org/MailArchives/boost/msg25583.php
Given the response, I am not surprised that there is no autoconf support in Boost.
?? If that's an "enormous flamewar" I should be burnt to a nuclear crisp by now. It looks like a relatively reasoned discussion to me. Am I missing something? -- Dave Abrahams Boost Consulting www.boost-consulting.com
Walter Landry <wlandry@ucsd.edu> writes:
Bjørn Roald <bjorn@4roald.org> wrote:
My view is very different from yours. The last thing that I want to do when I am installing a new program is learn about a new build system. On Unix, the install procedure should really be "configure ; make ; make install". There is really no excuse for that not to be the case.
I agree we should meet platform expectations. If make calls bjam or whatever, then so be it.
I would expect a binary installer on Windows.
I agree.
In fact, there should be a list of binary packages on the front page. If they don't exist for a platform (OS X?), they need to be built and offered there.
Well, they only need to be built and offered if there is enough demand to get someone to support it ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 4/16/05, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
"Rogier van Dalen" <rogiervd@gmail.com> wrote
I find installing Boost is pretty easy; but as long as one hasn't tried it yet, Boost may look scarily big.
There has been talk before
on something like "Boost Light". Combining concerns #1 and #2, wouldn't it be a good idea to supply a small subset of boost consisting of header-only libraries only?
I would have thought a system such as r.p.m / windows installer could be used. Is the requirement not just a remote version of the functionality of bcp ?. Tie this in to the http://www.boost.org/libs/libraries.htm with a suitable installer and it would certainly attract casual users.
What I meant is a "starter's package" with a few (often-used) libraries in it. As I said, I believe the problem may be not the number of megabytes, but the number of libraries (slightly more than 7 +- 2 :-). A remote version of bcp will only force potential users to educate themselves about all Boost libraries, and chase them away rather than attract them, I fear. Regards, Rogier
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"Rogier van Dalen" <rogiervd@gmail.com> wrote
I find installing Boost is pretty easy; but as long as one hasn't tried it yet, Boost may look scarily big.
There has been talk before
on something like "Boost Light". Combining concerns #1 and #2, wouldn't it be a good idea to supply a small subset of boost consisting of header-only libraries only?
I would have thought a system such as r.p.m / windows installer could be used. Is the requirement not just a remote version of the functionality of bcp ?. Tie this in to the http://www.boost.org/libs/libraries.htm with a suitable installer and it would certainly attract casual users.
It would be nice to be able to download and install just the parts you need, on the fly. I think that would make people feel a whole lot more comfortable.
Perhaps this represents dumbing down ?
You say that like it's a bad thing(?) -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
I would have thought a system such as r.p.m / windows installer could be used. Is the requirement not just a remote version of the functionality of bcp ?. Tie this in to the http://www.boost.org/libs/libraries.htm with a suitable installer and it would certainly attract casual users.
It would be nice to be able to download and install just the parts you need, on the fly. I think that would make people feel a whole lot more comfortable.
Well ...How about... running bcp on all the libs, zip them and add links to them in http://www.boost.org/libs/libraries.htm , (probably with info regarding whether they require compilation of source). A long way from the ideal method but relatively cheap (in time).
Perhaps this represents dumbing down ?
You say that like it's a bad thing(?)
No, I was trying to figure out why boost might think this isnt a good idea. regards Andy Little
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> writes:
----- Mensaje original ----- De: Robert Ramey <ramey@rrsd.com> Fecha: Viernes, Abril 15, 2005 6:05 pm Asunto: [boost] Re: Boost to the rescue
I'm amazed to discover that in only ONE single case have any of the programmers, managers, etc ever even heard of boost. This group even includes an ex head of the computer science department at a top tier university !!!
Speaking of which, I've got the nasty feeling that a good portion of the C++ programming community have heard of Boost but don't use it because:
1. It's too big. 2. It's too hard to install. 3. The docs are too technical. 4. They fear it's too "advanced" for them to understand it.
I've actually read comments on programmer sites touching on every one of these issues. My opinion is that:
* #1 is not that much of an issue in a world where people are happy to install a multimegabyte IDE and don't complain about it. When it comes to installing a library, somehow they measure size by a different standard.
I think they worry about interactions and "just how much foreign code am I using, anyway?" It's a perception thing, and it needs to be addressed.
* #2 is certainly a point, specially for Windows folks used to doubleclick on everything. Maybe it'd be a good idea to produce some graphical wizards (not necessarily as an official part of Boost) that automate the installation for at least the most commonly used platforms (read MS.) IMHO this would lower the entry barrier a lot.
Absolutely.
* As for #3 and #4, I've got this idea round my head that Boost would benefit of a "community site" where people of various expertise levels could mingle together, post Boost-related articles, etc. Something like CodeProject or Gamedev, which have a less intimidating appearance than www.boost.org. Some months ago I asked for a Boost-related forum in CodeProject, to no avail :(
Something wrong with boost-users? If so, I'd be happy to set up a forum at boost-consulting.com, if we can decide on the right software. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:ull74rkur.fsf@boost-consulting.com... <snip>
* As for #3 and #4, I've got this idea round my head that Boost would benefit of a "community site" where people of various expertise levels could mingle together, post Boost-related articles, etc. Something like CodeProject or Gamedev, which have a less intimidating appearance than www.boost.org. Some months ago I asked for a Boost-related forum in CodeProject, to no avail :(
Something wrong with boost-users?
IMHO, there's no comparison between boost-users and something like CodeProject. The way I see it, boost-users, is where I go ask a question when I'm stuck on something and can't find the right way on my own. CodeProject, on the other hand, is where I'd go publish about my "latest adventure" with boost (as in something I had to code, had a hard time doing it, managed to do it, and thought others might benefit from my experience & ready to use code), and read about others. The organization of the information available there is much better in terms of making things easy to find. (Article + discussions about it vs. lots of posts that are not always correctly threaded)
If so, I'd be happy to set up a forum at boost-consulting.com, if we can decide on the right software.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (20)
-
Andy Little -
Angus Leeming -
Bertolt Mildner -
Bjørn Roald -
David Abrahams -
Gennadiy Rozental -
Jeff Garland -
JOAQUIN LOPEZ MU?Z -
Jonathan Wakely -
nick＠ilm.com -
Pablo Aguilar -
Paul A Bristow -
Pavel Vozenilek -
Peter Simons -
Rene Rivera -
Rob Stewart -
Rogier van Dalen -
Victor A. Wagner Jr. -
Vladimir Prus -
Walter Landry