RE: [boost] Re: Customer Friendlier Boost Installation
----Original Message---- From: Jason Earl [mailto:Jason@hybd.net] Sent: 25 May 2005 15:32 To: boost@lists.boost.org Subject: Re: [boost] Re: Customer Friendlier Boost Installation
I think a lot of Windows users are too used to things just working out of the box, and give up if things don't work like that.
If you change that to "A lot of Windows users are used to things just working out of the box, and give up if things don't work like that", you have it exactly right. What is wrong with such expectation?
As for understanding what targets are etc, I think most developers will know what targets are.
I don't. If you use the Microsoft IDE, you never use the term. [snip]
Maybe it would be good to have some control over build verbosity (there probably already is some, I just haven't looked yet), Maybe logging the build info to a file would be better and then logging errors, messages etc to the screen (and maybe a separate) log file.
What people REALLY want, is to download headers + pre-built binaries. If they can't have that, then next best is a pretty gui which asks them all the questions (with the right defaults), and just works. If they can't have that, then really good documentation is required, and I don't think boost is there yet. -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434
Maybe it would be good to have some control over build verbosity (there probably already is some, I just haven't looked yet), Maybe logging the build info to a file would be better and then logging errors, messages etc to the screen (and maybe a separate) log file.
What people REALLY want, is to download headers + pre-built binaries.
What I really want, is a header only version of boost for download. I am allergic to linking, and I simply don't use any part of boost that can't be simply included. -- Christopher Diggins
christopher diggins wrote:
Maybe it would be good to have some control over build verbosity (there probably already is some, I just haven't looked yet), Maybe logging the build info to a file would be better and then logging errors, messages etc to the screen (and maybe a separate) log file.
What people REALLY want, is to download headers + pre-built binaries.
What I really want, is a header only version of boost for download. I am allergic to linking, and I simply don't use any part of boost that can't be simply included.
In that case your problem is solved. Just untar boost. Done.
----- Original Message ----- From: "Neal Becker" <ndbecker2@gmail.com>
What I really want, is a header only version of boost for download. I am allergic to linking, and I simply don't use any part of boost that can't be simply included.
In that case your problem is solved. Just untar boost. Done.
Unfortunately some libraries are not header only and there is easy way to tell which libraries require separate compilation / linking steps and which don't. I would very much like a separate release which only contained header only libraries. Christopher Diggins http://www.cdiggins.com
christopher diggins <cdiggins@videotron.ca> writes: | Unfortunately some libraries are not header only and there is easy way | to tell which libraries require separate compilation / linking steps | and which don't. I would very much like a separate release which only | contained header only libraries. I guess this is pretty close: ls boost/libs/*/src | grep : -- Lgb
christopher diggins <cdiggins@videotron.ca> writes:
----- Original Message ----- From: "Neal Becker" <ndbecker2@gmail.com>
What I really want, is a header only version of boost for download. I am allergic to linking, and I simply don't use any part of boost that can't be simply included.
In that case your problem is solved. Just untar boost. Done.
Unfortunately some libraries are not header only and there is easy way to tell which libraries require separate compilation / linking steps and which don't. I would very much like a separate release which only contained header only libraries.
Don't you think assembling a separate release of boost just so you can tell which libraries need to be compiled is a bit of a heavyweight approach? Seems to me a little documentation should be sufficient. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Unfortunately some libraries are not header only and there is easy way to tell which libraries require separate compilation / linking steps and which don't. I would very much like a separate release which only contained header only libraries.
Don't you think assembling a separate release of boost just so you can tell which libraries need to be compiled is a bit of a heavyweight approach? Seems to me a little documentation should be sufficient.
If there are a significant number of advanced users who, like myself, only use the header-only libraries, it would mean that there would be an overall saving of bandwidth. This also would include people doing casual downloads, such as curious newbies. So in that case I would not consider it to be a heavyweight approach, unless creating such a release would be a substantial amount of work for the release manager. This release I am proposing could alos be promoted as a lightweight release without documentation or tests. Boost-lite? Christopher Diggins http://www.cdiggins.com
christopher diggins <cdiggins@videotron.ca> writes:
Unfortunately some libraries are not header only and there is easy way to tell which libraries require separate compilation / linking steps and which don't. I would very much like a separate release which only contained header only libraries.
Don't you think assembling a separate release of boost just so you can tell which libraries need to be compiled is a bit of a heavyweight approach? Seems to me a little documentation should be sufficient.
If there are a significant number of advanced users who, like myself, only use the header-only libraries, it would mean that there would be an overall saving of bandwidth.
Bandwidth is hardly as valuable as volunteer time, IMO.
This also would include people doing casual downloads, such as curious newbies. So in that case I would not consider it to be a heavyweight approach, unless creating such a release would be a substantial amount of work for the release manager.
It would, unless you can figure out how to script it so it isn't.
This release I am proposing could alos be promoted as a lightweight release without documentation or tests. Boost-lite?
A release without documentation? <shudder> How will you discover which (header-only) libraries you have? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
christopher diggins <cdiggins@videotron.ca> writes:
Unfortunately some libraries are not header only and there is easy way to tell which libraries require separate compilation / linking steps and which don't. I would very much like a separate release which only contained header only libraries.
Don't you think assembling a separate release of boost just so you can tell which libraries need to be compiled is a bit of a heavyweight approach? Seems to me a little documentation should be sufficient.
If there are a significant number of advanced users who, like myself, only use the header-only libraries, it would mean that there would be an overall saving of bandwidth.
Bandwidth is hardly as valuable as volunteer time, IMO.
I think that splitting Boost in boost-hdronly and boost-libs will help a lot. There are a lot of thread or filesystem abstraction layers. But such unique libs like boost.lambda and MPL are header only, and can be used very easily without building bjam etc. It would be nice to have a separate package. Andrey
Andrey Melnikov <melnikov@simplexsoft.com> writes:
David Abrahams wrote:
christopher diggins <cdiggins@videotron.ca> writes:
Unfortunately some libraries are not header only and there is easy way to tell which libraries require separate compilation / linking steps and which don't. I would very much like a separate release which only contained header only libraries.
Don't you think assembling a separate release of boost just so you can tell which libraries need to be compiled is a bit of a heavyweight approach? Seems to me a little documentation should be sufficient.
If there are a significant number of advanced users who, like myself, only use the header-only libraries, it would mean that there would be an overall saving of bandwidth.
Bandwidth is hardly as valuable as volunteer time, IMO.
I think that splitting Boost in boost-hdronly and boost-libs will help a lot.
Help with what?
There are a lot of thread or filesystem abstraction layers. But such unique libs like boost.lambda and MPL are header only, and can be used very easily without building bjam etc.
Almost nobody needs to build bjam, since we provide prebuilt executables. Also, you can use those libraries very easily from a full package without building bjam.
It would be nice to have a separate package.
Undoubtedly it would be nice. Are you volunteering to prepare and maintain it? Would you include or exclude documentation? What about tests? What about examples? -- Dave Abrahams Boost Consulting www.boost-consulting.com
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams | Sent: 25 May 2005 20:34 | To: boost@lists.boost.org | Subject: [boost] Re: Customer Friendlier Boost Installation Seems to me a little documentation should be sufficient. | Dave Abrahams | Boost Consulting | www.boost-consulting.com I agree with this - and this was the thurst of my initial complaint/suggestion. A fancy GUI interface might be nice - but I think that it is a bit OTT. I am sure the bjam process does work - IMO it is only the instructions that are unsufficient. And they need to be TESTED for idiot-proofness by a GUI-only idiot - for which I am sure I am ideally qualified ;-) When I get back from holiday in a weeks time, I will pick up the suggestions and re-offer to comment/prepare something. 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 David Abrahams | Sent: 25 May 2005 20:34 | To: boost@lists.boost.org | Subject: [boost] Re: Customer Friendlier Boost Installation
Seems to me a little documentation should be sufficient.
| Dave Abrahams | Boost Consulting | www.boost-consulting.com
I agree with this - and this was the thurst of my initial complaint/suggestion.
A fancy GUI interface might be nice - but I think that it is a bit OTT. I am sure the bjam process does work - IMO it is only the instructions that are unsufficient.
But so far nobody has been able to make a concrete suggestion about how they can be improved, or even point to anything in the directions that's misleading. For example, when I asked you where things went wrong for you, you didn't answer. They do look crystal clear to me. So far, they only seem to fail for people who fail to follow the directions, IMO because they feel they're in alien command-line territory and get flustered. Maybe we just need a reassuring statement at the beginning.
And they need to be TESTED for idiot-proofness by a GUI-only idiot - for which I am sure I am ideally qualified ;-)
I think from Schobi's post I can conclude that the response of the build tool to badly-followed directions could be made more forgiving.
When I get back from holiday in a weeks time, I will pick up the suggestions and re-offer to comment/prepare something.
That would be great, but if you could just let us know where the instructions failed you first, it would be a big help. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Thu, May 26, 2005 at 08:55:59AM -0400, David Abrahams wrote:
They do look crystal clear to me. So far, they only seem to fail for people who fail to follow the directions, IMO because they feel they're in alien command-line territory and get flustered. Maybe we just need a reassuring statement at the beginning.
DON'T PANIC How about this? Worked for the best-selling book in the galaxy ;) jon
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
On Thu, May 26, 2005 at 08:55:59AM -0400, David Abrahams wrote:
They do look crystal clear to me. So far, they only seem to fail for people who fail to follow the directions, IMO because they feel they're in alien command-line territory and get flustered. Maybe we just need a reassuring statement at the beginning.
DON'T PANIC
How about this? Worked for the best-selling book in the galaxy ;)
I like it. Always good to start an adventure with a smile ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uzmuit3q9.fsf@boost-consulting.com...
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
On Thu, May 26, 2005 at 08:55:59AM -0400, David Abrahams wrote:
They do look crystal clear to me. So far, they only seem to fail for people who fail to follow the directions, IMO because they feel they're in alien command-line territory and get flustered. Maybe we just need a reassuring statement at the beginning.
DON'T PANIC
How about this? Worked for the best-selling book in the galaxy ;)
I like it. Always good to start an adventure with a smile ;-)
It's really not about command line versus GUI. It's just that default installation _should_ be one-button (or one batch command) operation. Instead, a simple requirement "install the quickbook" forses a person to: 1) check out Boost CVS; 2) build bjam; 3) figure out the difference between Boost.Build v1 and v2; 4) download and configire Boost.Build v2; 5) figure out how to build the quickbook (any info about this in the docs?) 6) download xslt processor from cygwin; 7) build the Boost.Book 8) Do whatever else (I am not even close to this right now). Sorry if I am somwhat off topic. Just waisting my day off, and being frustrated RIGHT NOW. Regards, Arkadiy
Arkadiy Vertleyb wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uzmuit3q9.fsf@boost-consulting.com...
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
DON'T PANIC
How about this? Worked for the best-selling book in the galaxy ;)
I like it. Always good to start an adventure with a smile ;-)
It's really not about command line versus GUI. It's just that default installation _should_ be one-button (or one batch command) operation.
Instead, a simple requirement "install the quickbook" forses a person to:
1) check out Boost CVS; 2) build bjam; 3) figure out the difference between Boost.Build v1 and v2; 4) download and configire Boost.Build v2; 5) figure out how to build the quickbook (any info about this in the docs?) 6) download xslt processor from cygwin; 7) build the Boost.Book 8) Do whatever else (I am not even close to this right now).
Sorry if I am somwhat off topic. Just waisting my day off, and being frustrated RIGHT NOW.
Try this one... Gets you a good part of the way there.. http://boost-sandbox.sourceforge.net/boost-cvs-setup.exe -- -- 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
Try this one... Gets you a good part of the way there..
Thanks -- it helped a lot! I was able to generate xml with the quickbook, but now having a trouble with the Boost.Book -- I guess something wrong with the Boost.Build configuration. Here is what I am getting when trying to build docs (as David suggested, I don't use BOOST_BUILD_PATH or boost-build.jam since I am in the Boost directory tree. But where does it get the Boost.Build from?): C:\boost_cvs\boost\doc>bjam --v2 warning: Python location is not configured warning: the Boost.Python library won't be built ****************************************************** Building Boost.Regex with Unicode/ICU support disabled. HINT: define the environment variable ICU_PATH to point to the root directy of your ICU installation if you have one. Couldn't find utypes.h in ****************************************************** warning: no toolsets are configured. warning: you won't be able to build C++ programs. warning: please consult the documentation. C:/boost_cvs/boost/tools/build/v2/build\targets.jam:1259: in construct from modu le object(typed-target)@8 error: unable to construct ../libs/program_options/build/boost_program_options C:/boost_cvs/boost/tools/build/v2/build\targets.jam:1142: in object(typed-target )@8.generate from module object(typed-target)@8 C:/boost_cvs/boost/tools/build/v2/build\targets.jam:757: in generate-really from module object(main-target)@10 C:/boost_cvs/boost/tools/build/v2/build\targets.jam:730: in object(main-target)@ 10.generate from module object(main-target)@10 C:/boost_cvs/boost/tools/build/v2/build\targets.jam:886: in targets.generate-fro m-reference from module targets C:/boost_cvs/boost/tools/build/v2/build\targets.jam:1080: in generate-dependenci es from module object(typed-target)@23 C:/boost_cvs/boost/tools/build/v2/build\targets.jam:1121: in object(typed-target )@23.generate from module object(typed-target)@23 C:/boost_cvs/boost/tools/build/v2/build\targets.jam:757: in generate-really from module object(main-target)@7 C:/boost_cvs/boost/tools/build/v2/build\targets.jam:730: in object(main-target)@ 7.generate from module object(main-target)@7 C:/boost_cvs/boost/tools/build/v2/build\targets.jam:252: in object(project-targe t)@20.generate from module object(project-target)@20 C:/boost_cvs/boost/tools/build/v2/tools\quickbook.jam:184: in object(quickbook-b inary-generator)@1.run from module object(quickbook-binary-generator)@1 C:/boost_cvs/boost/tools/build/v2/build\generators.jam:842: in try-one-generator -really from module generators C:/boost_cvs/boost/tools/build/v2/build\generators.jam:930: in try-one-generator from module generators C:/boost_cvs/boost/tools/build/v2/build\generators.jam:1197: in construct-really from module generators C:/boost_cvs/boost/tools/build/v2/build\generators.jam:1271: in generators.const ruct from module generators C:/boost_cvs/boost/tools/build/v2/build\targets.jam:1256: in construct from modu le object(typed-target)@21 C:/boost_cvs/boost/tools/build/v2/build\targets.jam:1142: in object(typed-target )@21.generate from module object(typed-target)@21 C:/boost_cvs/boost/tools/build/v2/build\targets.jam:757: in generate-really from module object(main-target)@5 C:/boost_cvs/boost/tools/build/v2/build\targets.jam:730: in object(main-target)@ 5.generate from module object(main-target)@5 C:/boost_cvs/boost/tools/build/v2/build\targets.jam:886: in targets.generate-fro m-reference from module targets C:/boost_cvs/boost/tools/build/v2/build\targets.jam:1080: in generate-dependenci es from module object(typed-target)@18 C:/boost_cvs/boost/tools/build/v2/build\targets.jam:1118: in object(typed-target )@18.generate from module object(typed-target)@18 C:/boost_cvs/boost/tools/build/v2/build\targets.jam:757: in generate-really from module object(main-target)@1 C:/boost_cvs/boost/tools/build/v2/build\targets.jam:730: in object(main-target)@ 1.generate from module object(main-target)@1 C:/boost_cvs/boost/tools/build/v2/build\targets.jam:252: in object(project-targe t)@16.generate from module object(project-target)@16 C:/boost_cvs/boost/tools/build/v2\build-system.jam:187: in load from module buil d-system C:\boost_cvs\boost\tools\build\v2/kernel\modules.jam:259: in import from module modules C:\boost_cvs\boost\tools\build\v2/kernel/bootstrap.jam:135: in boost-build from module C:\boost_cvs\boost\boost-build.jam:12: in module scope from module Thanks for any help. Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"Rene Rivera" <grafik.list@redshift-software.com> wrote
Try this one... Gets you a good part of the way there..
Thanks -- it helped a lot!
I was able to generate xml with the quickbook, but now having a trouble with the Boost.Book -- I guess something wrong with the Boost.Build configuration.
Here is what I am getting when trying to build docs (as David suggested, I don't use BOOST_BUILD_PATH or boost-build.jam since I am in the Boost directory tree. But where does it get the Boost.Build from?):
C:\boost_cvs\boost\doc>bjam --v2 warning: Python location is not configured warning: the Boost.Python library won't be built ******************************************************
Building Boost.Regex with Unicode/ICU support disabled. HINT: define the environment variable ICU_PATH to point to the root directy of your ICU installation if you have one. Couldn't find utypes.h in
****************************************************** warning: no toolsets are configured. warning: you won't be able to build C++ programs. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ warning: please consult the documentation.
C:/boost_cvs/boost/tools/build/v2/build\targets.jam:1259: in construct from modu le object(typed-target)@8 error: unable to construct ../libs/program_options/build/boost_program_options ^^^^^^^^^^^^^^^^^^^^^
That's a C++ library. I see a correlation here ;-) How about editing your user-config.jam file? You can copy it from tools/build/v2/user-config.jam into your $HOME directory. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote
error: unable to construct ../libs/program_options/build/boost_program_options ^^^^^^^^^^^^^^^^^^^^^
That's a C++ library. I see a correlation here ;-)
How about editing your user-config.jam file? You can copy it from tools/build/v2/user-config.jam into your $HOME directory.
I guess I am missing the whole picture here... What are the pieces I need? 1) bjam -- I got it with Rene's install, and it's in my path. I assume nothing else need to be done about it... 2) Boost.Build 2 -- a bunch of jam files, tool description files, etc. Does it come as a part of Boost? When I have boost-build.jam, I understand where it's taken from, but since I removed it... Is it comming as a part of the current Boost tree? I have boost_1_32_0, Boost CVS, and Boost Sandbox CVS. Should I use different Boost.Build in each tree? And I don't think 3) What is my $HOME directory? The boost-sandbox\libs\typeof\doc? Assumming that I am trying to build the documentation... And if I build the tests, will my $HOME be different? Besides I don't see Boost.Build in the Boost Sandbox CVS... Regards, Arkadiy
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
error: unable to construct ../libs/program_options/build/boost_program_options ^^^^^^^^^^^^^^^^^^^^^
That's a C++ library. I see a correlation here ;-)
How about editing your user-config.jam file? You can copy it from tools/build/v2/user-config.jam into your $HOME directory.
I guess I am missing the whole picture here... What are the pieces I need?
1) bjam -- I got it with Rene's install, and it's in my path. I assume nothing else need to be done about it...
I don't know enough about Rene's thing to tell you for sure, but if Rene installed a pre-built binary and hasn't recently updated his installer program and you are using Boost's CVS you probably need a more up-to-date version of bjam than the one he supplied you with, because the CVS version of Boost.Build is using some features that were recently added to bjam. So I'd rebuild it -- it's trivial; just go to the tools/build/jam_src subdirectory of your boost distro and type C:\boost_cvs\boost\tools\build\jam_src> build The result is in bin.ntx86\bjam.
2) Boost.Build 2 -- a bunch of jam files, tool description files, etc. Does it come as a part of Boost?
Yes. C:\boost_cvs\boost\tools\build\v2 This is all detailed at http://engineering.meta-comm.com/resources/cs-win32_metacomm/doc/html/bbv2/i...
When I have boost-build.jam, I understand where it's taken from, but since I removed it...
Not sure I understand, but probably doesn't matter.
Is it comming as a part of the current Boost tree?
C:\boost_cvs\boost\boost-build.jam
I have boost_1_32_0, Boost CVS, and Boost Sandbox CVS. Should I use different Boost.Build in each tree?
I might use the latest CVS Boost.Build in each tree, although you can use the BBv2 from 1.32.0 in the boost_1_32_0 tree if you like. The latter is easier, as you won't have to replace boost-build.jam there or point BOOST_BUILD_PATH at c:\boost_cvs\boost\tools\build\v2. The boost-build.jam at the root of the sandbox CVS works by default if the sandbox image is right next to the boost image, but if not you can always set BOOST=c:\boost_cvs\boost in your environment or put -sBOOST=c:\boost_cvs\boost on your bjam command-line and it will set up your include paths correctly in sandbox projects (at least mine; I can't vouch for what other people did).
And I don't think
??
3) What is my $HOME directory? The boost-sandbox\libs\typeof\doc?
Sorry, that was a Unix-ism. Just set HOME=%HOMEPATH% and it will be in c:\Documents and Settings\<your-user-name> We ought to change it so it uses %HOMEPATH% instead of %HOME% by default, on Windows.
Assumming that I am trying to build the documentation... And if I build the tests, will my $HOME be different?
No, $HOME == %HOME% i.e. whatever directory you set the HOME variable to.
Besides I don't see Boost.Build in the Boost Sandbox CVS...
Not a problem. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
error: unable to construct ../libs/program_options/build/boost_program_options
^^^^^^^^^^^^^^^^^^^^^
That's a C++ library. I see a correlation here ;-)
How about editing your user-config.jam file? You can copy it from tools/build/v2/user-config.jam into your $HOME directory.
I guess I am missing the whole picture here... What are the pieces I need?
1) bjam -- I got it with Rene's install, and it's in my path. I assume nothing else need to be done about it...
I don't know enough about Rene's thing to tell you for sure, but if Rene installed a pre-built binary and hasn't recently updated his installer program and you are using Boost's CVS you probably need a more up-to-date version of bjam than the one he supplied you with, because the CVS version of Boost.Build is using some features that were recently added to bjam.
It's a build from yesterday's CVS state :-) I haven't updated it to contain the changes to bjam I've done today. I tried running "bjam --v2" in the docs directory and I don't get the above error. This is because I do set up all the tools possible, msvc, cw, python, xsltproc, boostbook, doxygen, and quickbook, with the attached user-config.jam. My guess is that since Arkadiy did not have a user-config.jam, and hence did not set up the boostbook tools, it defaulted to trying to build them. But since a C++ compiler was not available it fails even 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 ECHO @@@ HOME/user-config.jam ; import msvc-config ; import cw-config ; import python-config ; import xsltproc-config ; import boostbook-config ; import doxygen-config ; import quickbook-config ;
"David Abrahams" <dave@boost-consulting.com> wrote in message news:upsvdfl14.fsf@boost-consulting.com...
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
[snip]
3) What is my $HOME directory? The boost-sandbox\libs\typeof\doc?
Sorry, that was a Unix-ism. Just
set HOME=%HOMEPATH%
Actually, I think that this should be: set HOME=%HOMEDRIVE%%HOMEPATH%
and it will be in c:\Documents and Settings\<your-user-name>
For me, it's actually "d:\users\jni" - but normally it defaults to be the above. I usally change the user settings to have my home path somewhere else.
We ought to change it so it uses %HOMEPATH% instead of %HOME% by default, on Windows.
As above. // Johan
"Johan Nilsson" <r.johan.nilsson@gmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:upsvdfl14.fsf@boost-consulting.com...
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
[snip]
3) What is my $HOME directory? The boost-sandbox\libs\typeof\doc?
Sorry, that was a Unix-ism. Just
set HOME=%HOMEPATH%
Actually, I think that this should be:
set HOME=%HOMEDRIVE%%HOMEPATH%
Done. I tried to create a regression test for this, but I couldn't get the test system to pass environment variable settings down to the invoked bjam process. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Johan Nilsson" <r.johan.nilsson@gmail.com> writes:
Actually, I think that this should be:
set HOME=%HOMEDRIVE%%HOMEPATH%
Done.
I tried to create a regression test for this, but I couldn't get the test system to pass environment variable settings down to the invoked bjam process.
I think this broke my Windows build environment. I had an envar HOME=C:\home, but a freshly built bjam.exe was unable to find my user-config.jam until I defined HOMEDRIVE and HOMEPATH also. Was this intentional? -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
David Abrahams wrote:
"Johan Nilsson" <r.johan.nilsson@gmail.com> writes:
Actually, I think that this should be:
set HOME=%HOMEDRIVE%%HOMEPATH%
Done.
I tried to create a regression test for this, but I couldn't get the test system to pass environment variable settings down to the invoked bjam process.
I think this broke my Windows build environment. I had an envar HOME=C:\home, but a freshly built bjam.exe was unable to find my user-config.jam until I defined HOMEDRIVE and HOMEPATH also. Was this intentional?
What Windows? Without further ado in a dos-prompt on WinXP: C:>set home HOMEDRIVE=C: HOMEPATH=\Documents and Settings\Brian Riis Windows defines these by itself. (At least it should). Of course it'll not point into your C:\home directory, but using it should be "portable" across Windows versions *without* setting any environment variables. Your user-config.jam will have to go into C:\Documents and Settings\<your login>\, of course. -- /Brian Riis
"Brian Ravnsgaard Riis" <brian@riis.as> wrote in message news:429CE628.60601@riis.as...
Eric Niebler wrote:
[snip]
I think this broke my Windows build environment. I had an envar HOME=C:\home, but a freshly built bjam.exe was unable to find my user-config.jam until I defined HOMEDRIVE and HOMEPATH also. Was this intentional?
What Windows? Without further ado in a dos-prompt on WinXP:
C:>set home HOMEDRIVE=C: HOMEPATH=\Documents and Settings\Brian Riis
Windows defines these by itself. (At least it should). Of course it'll not point into your C:\home directory, but using it should be "portable" across Windows versions *without* setting any environment variables. Your user-config.jam will have to go into C:\Documents and Settings\<your login>\, of course.
HOMEDRIVE and HOMEPATH does not necessarily point to that specific directory. // Johan
Johan Nilsson wrote:
HOMEDRIVE and HOMEPATH does not necessarily point to that specific directory.
No. Which is why the location is stored in env vars. Still, what led to this was whether to use %HOME% or %HOMEDRIVE%%HOMEPATH% on Windows. I say the latter, as those envvars exist. The former doesn't, unless you (have) set it explicitly.
// Johan
-- /Brian Riis
"Eric Niebler" <eric@boost-consulting.com> writes:
David Abrahams wrote:
"Johan Nilsson" <r.johan.nilsson@gmail.com> writes:
Actually, I think that this should be:
set HOME=%HOMEDRIVE%%HOMEPATH%
Done.
I tried to create a regression test for this, but I couldn't get the test system to pass environment variable settings down to the invoked bjam process.
I think this broke my Windows build environment. I had an envar HOME=C:\home, but a freshly built bjam.exe was unable to find my user-config.jam until I defined HOMEDRIVE and HOMEPATH also. Was this intentional?
No! It's supposed to check %HOMEDRIVE%%HOMEPATH% first, then %HOME%, then %BOOST_BUILD_PATH%. I'll look at this. Just out of curiosity: why weren't HOMEDRIVE and HOMEPATH set in your environment? Aren't they set up for you by Windows? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
"Eric Niebler" <eric@boost-consulting.com> writes:
David Abrahams wrote:
"Johan Nilsson" <r.johan.nilsson@gmail.com> writes:
Actually, I think that this should be:
set HOME=%HOMEDRIVE%%HOMEPATH%
Done.
I tried to create a regression test for this, but I couldn't get the test system to pass environment variable settings down to the invoked bjam process.
I think this broke my Windows build environment. I had an envar HOME=C:\home, but a freshly built bjam.exe was unable to find my user-config.jam until I defined HOMEDRIVE and HOMEPATH also. Was this intentional?
No! It's supposed to check %HOMEDRIVE%%HOMEPATH% first, then %HOME%, then %BOOST_BUILD_PATH%. I'll look at this.
Should be fixed now.
Just out of curiosity: why weren't HOMEDRIVE and HOMEPATH set in your environment? Aren't they set up for you by Windows?
Still curious, though. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Just out of curiosity: why weren't HOMEDRIVE and HOMEPATH set in your environment? Aren't they set up for you by Windows?
Still curious, though.
Not all the time, and Windows never ceases to amaze and frustrate me. It turns out that if you lauch a cmd.exe shell as another user, then you don't get these environment variables defined for some reason. Try it and see: Start -> All Programs -> Accessories Now, hold down Shift while right-clicking on "Command Prompt" and select "Run As...". Give the credentials of a different user to have the cmd.exe process lauch as that user. Now observe that the shell has no HOMEDRIVE and HOMEPATH environment variables!!! Sigh. -- Eric Niebler Boost Consulting www.boost-consulting.com
David Abrahams wrote:
No! It's supposed to check %HOMEDRIVE%%HOMEPATH% first, then %HOME%, then %BOOST_BUILD_PATH%. I'll look at this.
I think this is backwards. If someone has gone through the trouble of setting a HOME environment variable, that one should be preferred over %HOMEDRIVE%%HOMEPATH%. Consider that many people out there have probably defined HOME for the sole purpose of making bjam work (I'm one of them). This change will break them by causing bjam to look someplace else for user-config.jam. -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" <eric@boost-consulting.com> writes:
David Abrahams wrote:
No! It's supposed to check %HOMEDRIVE%%HOMEPATH% first, then %HOME%, then %BOOST_BUILD_PATH%. I'll look at this.
I think this is backwards. If someone has gone through the trouble of setting a HOME environment variable, that one should be preferred over %HOMEDRIVE%%HOMEPATH%. Consider that many people out there have probably defined HOME for the sole purpose of making bjam work (I'm one of them). This change will break them by causing bjam to look someplace else for user-config.jam.
You really think it's likely that they've set up HOME and yet have installed a user-config.jam that they don't want bjam to use in %HOMEDRIVE%%HOMEPATH%? I don't. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
You really think it's likely that they've set up HOME and yet have installed a user-config.jam that they don't want bjam to use in %HOMEDRIVE%%HOMEPATH%? I don't.
Haha, ok. You're right. But as it so happens, this was exactly the case on my machine. I struggled to get bjam working the first time, and in the process, I scattered user-config.jam all over the place. I ended up with one in %HOME% and a turd user-config.jam in %HOMEDRIVE%%HOMEPATH% (which I just deleted to be safe). -- Eric Niebler Boost Consulting www.boost-consulting.com
"Eric Niebler" <eric@boost-consulting.com> writes:
David Abrahams wrote:
You really think it's likely that they've set up HOME and yet have installed a user-config.jam that they don't want bjam to use in %HOMEDRIVE%%HOMEPATH%? I don't.
Haha, ok. You're right. But as it so happens, this was exactly the case on my machine. I struggled to get bjam working the first time, and in the process, I scattered user-config.jam all over the place. I ended up with one in %HOME% and a turd user-config.jam in %HOMEDRIVE%%HOMEPATH% (which I just deleted to be safe).
Well, I'll take you to be an outlier. Backward compatibility is less important at this point in BBv2 than just getting things right. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Johan Nilsson" <r.johan.nilsson@gmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:upsvdfl14.fsf@boost-consulting.com...
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
[snip]
3) What is my $HOME directory? The boost-sandbox\libs\typeof\doc?
Sorry, that was a Unix-ism. Just
set HOME=%HOMEPATH%
Actually, I think that this should be:
set HOME=%HOMEDRIVE%%HOMEPATH%
Done.
I tried to create a regression test for this, but I couldn't get the test system to pass environment variable settings down to the invoked bjam process.
Do we really need these environment vars? I just put boost-build.jam (as documentation suggests) into my \projects folder, and everything below \project detects boost.build perfectly. I really hate making system-wide changes, like setting environment variables globally. Andrey
Andrey Melnikov <melnikov@simplexsoft.com> writes:
David Abrahams wrote:
"Johan Nilsson" <r.johan.nilsson@gmail.com> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:upsvdfl14.fsf@boost-consulting.com...
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
[snip]
3) What is my $HOME directory? The boost-sandbox\libs\typeof\doc?
Sorry, that was a Unix-ism. Just
set HOME=%HOMEPATH%
Actually, I think that this should be:
set HOME=%HOMEDRIVE%%HOMEPATH%
Done.
I tried to create a regression test for this, but I couldn't get the test system to pass environment variable settings down to the invoked bjam process.
Do we really need these environment vars? I just put boost-build.jam (as documentation suggests) into my \projects folder, and everything below \project detects boost.build perfectly.
That is a completely separate issue. The question is, where will user-config.jam be looked for? It is a BBv2 question, and environment variables are actually irrelevant. The set command above is just the way of describing where BBv2 should look for it on Windows systems.
I really hate making system-wide changes, like setting environment variables globally.
You can rest assured that the ability to avoid setting environment variables has been a design goal of Boost.Build since version 1 was begun. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Johan Nilsson wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:upsvdfl14.fsf@boost-consulting.com...
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
3) What is my $HOME directory? The boost-sandbox\libs\typeof\doc?
Sorry, that was a Unix-ism. Just
set HOME=%HOMEPATH%
Actually, I think that this should be:
set HOME=%HOMEDRIVE%%HOMEPATH%
and it will be in c:\Documents and Settings\<your-user-name>
For me, it's actually "d:\users\jni" - but normally it defaults to be the above. I usally change the user settings to have my home path somewhere else.
We ought to change it so it uses %HOMEPATH% instead of %HOME% by default, on Windows.
I have both HOME, HOMEPATH and HOMEDRIVE. Is HOME non-standard on Windows? Andrey
Andrey Melnikov <melnikov@simplexsoft.com> writes:
Johan Nilsson wrote:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:upsvdfl14.fsf@boost-consulting.com...
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
3) What is my $HOME directory? The boost-sandbox\libs\typeof\doc?
Sorry, that was a Unix-ism. Just
set HOME=%HOMEPATH%
Actually, I think that this should be:
set HOME=%HOMEDRIVE%%HOMEPATH%
and it will be in c:\Documents and Settings\<your-user-name>
For me, it's actually "d:\users\jni" - but normally it defaults to be the above. I usally change the user settings to have my home path somewhere else.
We ought to change it so it uses %HOMEPATH% instead of %HOME% by default, on Windows.
I have both HOME, HOMEPATH and HOMEDRIVE. Is HOME non-standard on Windows?
Yes. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:uzmuit3q9.fsf@boost-consulting.com...
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
On Thu, May 26, 2005 at 08:55:59AM -0400, David Abrahams wrote:
They do look crystal clear to me. So far, they only seem to fail for people who fail to follow the directions, IMO because they feel they're in alien command-line territory and get flustered. Maybe we just need a reassuring statement at the beginning.
DON'T PANIC
How about this? Worked for the best-selling book in the galaxy ;)
I like it. Always good to start an adventure with a smile ;-)
And a Towel! Jeff Flinn
participants (14)
-
Andrey Melnikov -
Arkadiy Vertleyb -
Brian Ravnsgaard Riis -
christopher diggins -
David Abrahams -
Eric Niebler -
Jeff Flinn -
Johan Nilsson -
Jonathan Wakely -
larsbj＠gullik.net -
Martin Bonner -
Neal Becker -
Paul A Bristow -
Rene Rivera