RE: [boost] Re: Customer Friendlier Boost Installation
Wild thought- Is there a rational way to have a "environment" checker. I am NOT a bjam expert- but it would be handy if we had some cmd line program that would follow spit out all the info BJAM looks for and finds. I am slightly half cocked in this idea, but basically it would have to be enough information that you could get a better sense for what Bjam was doing Something like C:\boost\> boostenvcheck.exe ** Enviroment Report** Python is not in the path User-config.jam file is setup to use gcc, vc7.1 Etc.... I have been using boost for (has it been that long) 2 years now. Bjam still confounds me. ( I appreciate the work effort, it is a cool tool, I remain struggling with it though) (I am also a tad frustrated because I have been trying to make vc7.1 build wave for the last 5 hours) Semi-Related: I proposed (a long time ago) building a SIMPLE gui framework- with the core elements, and then making a "boost environment checker" out of that- I.e. imagine a tree control with all the types of settings and what nots, and the ability to navigate this gui to try to determine what is not set correctly.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Lars Gullik Bjønnes Sent: Thursday, May 26, 2005 3:27 AM To: boost@lists.boost.org Subject: [boost] Re: Customer Friendlier Boost Installation
"Hendrik Schober" <SpamTrap@gmx.de> writes:
| Lars Gullik Bjønnes <larsbj@gullik.net> wrote:
David Abrahams <dave@boost-consulting.com> writes:
| We never wanted to be the sole province of experts. We always wanted | widespread usage. If you want to be a member of an exclusive | "experts" club this is the wrong place to find it.
Sure. But there, imho, must be a difference expected between _users_ of the libraries, and _installers_ (or packagers) of the libraries.
| How so? Shall people employ an administrator to | install the libs they want to check out?
No. But IMHO it should be expect that it is a bit harder to install (and in this case it is build as well) the library than use it.
So: Create an windows installer and then the user can use that.
-- Lgb
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I don't know anything about boost installation on windows, since I'm using a prebuilt debian package, and that's my point: from the discussion it seems the building process is not as easy as it could be. so, isn't it a better choice to provide binary packages for the most popular compilers instead of writing an installer? Am Donnerstag, 26. Mai 2005 13:21 schrieb Brian Braatz:
Wild thought-
Is there a rational way to have a "environment" checker. I am NOT a bjam expert- but it would be handy if we had some cmd line program that would follow spit out all the info BJAM looks for and finds.
I am slightly half cocked in this idea, but basically it would have to be enough information that you could get a better sense for what Bjam was doing
Something like
C:\boost\> boostenvcheck.exe ** Enviroment Report** Python is not in the path User-config.jam file is setup to use gcc, vc7.1 Etc....
I have been using boost for (has it been that long) 2 years now. Bjam still confounds me. ( I appreciate the work effort, it is a cool tool, I remain struggling with it though)
(I am also a tad frustrated because I have been trying to make vc7.1 build wave for the last 5 hours)
Semi-Related:
I proposed (a long time ago) building a SIMPLE gui framework- with the core elements, and then making a "boost environment checker" out of that- I.e. imagine a tree control with all the types of settings and what nots, and the ability to navigate this gui to try to determine what is not set correctly.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Lars Gullik Bjønnes Sent: Thursday, May 26, 2005 3:27 AM To: boost@lists.boost.org Subject: [boost] Re: Customer Friendlier Boost Installation
"Hendrik Schober" <SpamTrap@gmx.de> writes: | Lars Gullik Bjønnes <larsbj@gullik.net> wrote:
David Abrahams <dave@boost-consulting.com> writes: | We never wanted to be the sole province of experts. We always | wanted widespread usage. If you want to be a member of an exclusive | "experts" club this is the wrong place to find it.
Sure. But there, imho, must be a difference expected between _users_ of the libraries, and _installers_ (or packagers) of the libraries. | | How so? Shall people employ an administrator to | install the libs they want to check out?
No. But IMHO it should be expect that it is a bit harder to install (and in this case it is build as well) the library than use it.
So: Create an windows installer and then the user can use that.
-- Lgb
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Stefan Strasser
Stefan Strasser <sstrasser@systemhaus-gruppe.de> writes:
I don't know anything about boost installation on windows, since I'm using a prebuilt debian package, and that's my point:
from the discussion it seems the building process is not as easy as it could be. so, isn't it a better choice to provide binary packages for the most popular compilers instead of writing an installer?
A binary package for the most popular compiler (VC++) is an installer. That's the way binary packages are delivered on Windows. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Stefan Strasser <sstrasser@systemhaus-gruppe.de> writes:
I don't know anything about boost installation on windows, since I'm using a prebuilt debian package, and that's my point:
from the discussion it seems the building process is not as easy as it could be. so, isn't it a better choice to provide binary packages for the most popular compilers instead of writing an installer?
A binary package for the most popular compiler (VC++) is an installer. That's the way binary packages are delivered on Windows.
A binary package of the .zip variety would be both good enough and preferable, as it wouldn't involve running untrusted executables. That aside, FWIW I've found bjam relatively painless to use (once it's present). I didn't even need to specify an -sTOOLS option or run vcvars32.bat IIRC. For the scenario where one already has the headers up and running but doesn't want to "bjam install" the whole package, the main obstacle is figuring out which -sBUILD combination generates "library-sgd-mt-whatever" when autolinking kicks in. Or can bjam figure these out automatically from the target name of "library-sgd-mt-whatever.lib"? It didn't occur to me to try it. ;-)
"Peter Dimov" <pdimov@mmltd.net> writes:
That aside, FWIW I've found bjam relatively painless to use (once it's present). I didn't even need to specify an -sTOOLS option or run vcvars32.bat IIRC. For the scenario where one already has the headers up and running but doesn't want to "bjam install" the whole package, the main obstacle is figuring out which -sBUILD combination generates "library-sgd-mt-whatever" when autolinking kicks in.
Or can bjam figure these out automatically from the target name of "library-sgd-mt-whatever.lib"? It didn't occur to me to try it. ;-)
No, it can't. The presumption is that -SBUILD="..." specifications are higher level than sgd-mt-whatever abbreviated tag strings. Of course, -sBUILD is still pretty awful in v1. In v2 you just write, e.g. bjam threading=multi link=static <library-name> if you want to build a library with specific options. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
That aside, FWIW I've found bjam relatively painless to use (once it's present). I didn't even need to specify an -sTOOLS option or run vcvars32.bat IIRC. For the scenario where one already has the headers up and running but doesn't want to "bjam install" the whole package, the main obstacle is figuring out which -sBUILD combination generates "library-sgd-mt-whatever" when autolinking kicks in.
Or can bjam figure these out automatically from the target name of "library-sgd-mt-whatever.lib"? It didn't occur to me to try it. ;-)
No, it can't. The presumption is that -SBUILD="..." specifications are higher level than sgd-mt-whatever abbreviated tag strings. Of course, -sBUILD is still pretty awful in v1. In v2 you just write, e.g.
bjam threading=multi link=static <library-name>
if you want to build a library with specific options.
This is better. But my point is that the linker doesn't tell me anything about threading=multi or link=static. It tells me the exact name of the .lib file, and I'm supposed to reverse engineer the sgd-mt-whatever string and come up with the higher-level options. If I am expected to be able to do that, so can Boost.Build, right? It can even get them right the first time. I average about 2.5 tries.
Peter Dimov wrote:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
That aside, FWIW I've found bjam relatively painless to use (once it's present). I didn't even need to specify an -sTOOLS option or run vcvars32.bat IIRC. For the scenario where one already has the headers up and running but doesn't want to "bjam install" the whole package, the main obstacle is figuring out which -sBUILD combination generates "library-sgd-mt-whatever" when autolinking kicks in.
Or can bjam figure these out automatically from the target name of "library-sgd-mt-whatever.lib"? It didn't occur to me to try it. ;-)
No, it can't. The presumption is that -SBUILD="..." specifications are higher level than sgd-mt-whatever abbreviated tag strings. Of course, -sBUILD is still pretty awful in v1. In v2 you just write, e.g.
bjam threading=multi link=static <library-name>
if you want to build a library with specific options.
This is better. But my point is that the linker doesn't tell me anything about threading=multi or link=static. It tells me the exact name of the .lib file, and I'm supposed to reverse engineer the sgd-mt-whatever string and come up with the higher-level options. If I am expected to be able to do that, so can Boost.Build, right? It can even get them right the first time. I average about 2.5 tries.
I think it would be possible to add the pseudo-targets so that doing: bjam libboost_thread-vc71-mt-1_33.lib Would be, in BBv1, equivalent to: bjam "-sBUILD=release <runtime-link>dynamic/<threading>multi" --with-thread stage Something similar could be done in BBv2. -- -- 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> writes:
I think it would be possible to add the pseudo-targets so that doing:
bjam libboost_thread-vc71-mt-1_33.lib
Would be, in BBv1, equivalent to:
bjam "-sBUILD=release <runtime-link>dynamic/<threading>multi" --with-thread stage
Something similar could be done in BBv2.
But not with pseudo-targets. We actually decide what Jam targets to generate based on the command-line, rather than generating the world and letting jam build the ones specified. In fact BBv1 does the same in part. You'd still have to extract and interpret the toolset tag before deciding what to generate. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Rene Rivera wrote:
Peter Dimov wrote:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes: For the scenario where one already has the
headers up and running but doesn't want to "bjam install" the whole package, the main obstacle is figuring out which -sBUILD combination generates "library-sgd-mt-whatever" when autolinking kicks in.
Or can bjam figure these out automatically from the target name of "library-sgd-mt-whatever.lib"? It didn't occur to me to try it. ;-)
No, it can't. The presumption is that -SBUILD="..." specifications are higher level than sgd-mt-whatever abbreviated tag strings. Of course, -sBUILD is still pretty awful in v1. In v2 you just write, e.g.
bjam threading=multi link=static <library-name>
if you want to build a library with specific options.
This is better. But my point is that the linker doesn't tell me anything about threading=multi or link=static. It tells me the exact name of the .lib file, and I'm supposed to reverse engineer the sgd-mt-whatever string and come up with the higher-level options. If I am expected to be able to do that, so can Boost.Build, right? It can even get them right the first time. I average about 2.5 tries.
I think it would be possible to add the pseudo-targets so that doing:
bjam libboost_thread-vc71-mt-1_33.lib
Would be, in BBv1, equivalent to:
bjam "-sBUILD=release <runtime-link>dynamic/<threading>multi" --with-thread stage
Something similar could be done in BBv2.
Actually we don't have to be very precise. I wouldn't complain if I had just a piece of documentation how to build ALL [lib]boost_thread-vc71-*-1_33 flavours at once. Can anyone give me such examples for both bbv1 and bbv2? Andrey
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
"Peter Dimov" <pdimov@mmltd.net> writes:
Or can bjam figure these out automatically from the target name of "library-sgd-mt-whatever.lib"? It didn't occur to me to try it. ;-)
No, it can't. The presumption is that -SBUILD="..." specifications are higher level than sgd-mt-whatever abbreviated tag strings. Of course, -sBUILD is still pretty awful in v1. In v2 you just write, e.g.
bjam threading=multi link=static <library-name>
if you want to build a library with specific options.
This is better. But my point is that the linker doesn't tell me anything about threading=multi or link=static. It tells me the exact name of the .lib file, and I'm supposed to reverse engineer the sgd-mt-whatever string and come up with the higher-level options.
Oh, weird. I just never thought of it from the angle that you're going to wait for an error and then figure out what to build. But I suppose you'll have the same problem if you built the wrong thing to begin with; then you'll still have to poke around to figure out how the system wants you to describe the library.
If I am expected to be able to do that, so can Boost.Build, right?
Well, let me put it this way: in theory it can, but the library name can't be treated like an ordinary target. We could see if we can find a target with that name, and if not, try to decode it as a tagged library name and construct a new virtual command-line.
It can even get them right the first time. I average about 2.5 tries.
:) Good idea. Could you put this on http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Build_V... ? -- Dave Abrahams Boost Consulting www.boost-consulting.com
Peter Dimov wrote:
David Abrahams wrote:
A binary package of the .zip variety would be both good enough and preferable, as it wouldn't involve running untrusted executables.
Well, running and MSI doesn't involve untrusted executables either :) .zip package with prebuilt libs will be good enough. It's a good compromise between ease of installation and ease of package creation.
That aside, FWIW I've found bjam relatively painless to use (once it's present). I didn't even need to specify an -sTOOLS option or run vcvars32.bat IIRC.
The documentation is misleading and outdated. BBv1 Getting Started tells you to do complex things which aren't already necessary for a long time.
For the scenario where one already has the headers up and running but doesn't want to "bjam install" the whole package, the main obstacle is figuring out which -sBUILD combination generates "library-sgd-mt-whatever" when autolinking kicks in.
Or can bjam figure these out automatically from the target name of "library-sgd-mt-whatever.lib"? It didn't occur to me to try it. ;-)
Good idea. Andrey
At 05:11 2005-05-26, Stefan Strasser wrote:
I don't know anything about boost installation on windows, since I'm using a prebuilt debian package, and that's my point:
from the discussion it seems the building process is not as easy as it could be. so, isn't it a better choice to provide binary packages for the most popular compilers instead of writing an installer?
a dir (ls -l for you *nix folks) of *71*33* in my boost built libraries shows 126 File(s) 652,626,996 bytes I suspect most people would balk at downloading something like that (especially since much of boost can be used withOUT building anything)
-- Stefan Strasser
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Victor A. Wagner Jr. wrote:
At 05:11 2005-05-26, Stefan Strasser wrote:
I don't know anything about boost installation on windows, since I'm using a prebuilt debian package, and that's my point:
from the discussion it seems the building process is not as easy as it could be. so, isn't it a better choice to provide binary packages for the most popular compilers instead of writing an installer?
a dir (ls -l for you *nix folks) of *71*33* in my boost built libraries shows 126 File(s) 652,626,996 bytes I suspect most people would balk at downloading something like that (especially since much of boost can be used withOUT building anything)
Your expectations are wrong. MS libraries compress very well, so it would take about 30 mbs. Try to bzip or 7zip the files and look at the miracle. Also, we need to have header-only package as we discussed earlier. Andrey
"Brian Braatz" <brianb@rmtg.com> writes:
Wild thought-
Is there a rational way to have a "environment" checker. I am NOT a bjam expert- but it would be handy if we had some cmd line program that would follow spit out all the info BJAM looks for and finds.
I am slightly half cocked in this idea, but basically it would have to be enough information that you could get a better sense for what Bjam was doing
Something like
C:\boost\> boostenvcheck.exe ** Enviroment Report** Python is not in the path User-config.jam file is setup to use gcc, vc7.1 Etc....
If you're talking about user-config.jam you're talking about BBv2. First question: how would this information help people? They can go look at their user-config.jam themselves, right? First problem: .jam files are programs, not just configuration, like .ini files. We can't capture everything a user might want to write there in English.
I have been using boost for (has it been that long) 2 years now. Bjam still confounds me. ( I appreciate the work effort, it is a cool tool, I remain struggling with it though)
You never post questions; how can we improve its interface and help you understand it otherwise?
(I am also a tad frustrated because I have been trying to make vc7.1 build wave for the last 5 hours)
Semi-Related:
I proposed (a long time ago) building a SIMPLE gui framework- with the core elements, and then making a "boost environment checker" out of that- I.e. imagine a tree control with all the types of settings and what nots, and the ability to navigate this gui to try to determine what is not set correctly.
Might be a good idea; we can't really know until we see one, though. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
Andrey Melnikov -
Brian Braatz -
David Abrahams -
Peter Dimov -
Rene Rivera -
Stefan Strasser -
Victor A. Wagner Jr.