Hi, group After some years staying away from boost, I installed the 1.32 release. The system was WinXP with VC6. I used the .exe variant. Take the following as remarks from an innocent, also if some of the issues seem to be trivial. Even though, I'm a C++ developer for more than 10 years now. I have used literally thousends of programs and libraries and I know, how quickly someone decides to skip the usage of software completely, simply because the installation becomes too strenous. The story: The exe is in fact an archive. This should be stated, because it suggests some form of installer. Starting with bjam "-sTOOLS=msvc" stage first of all I got without bigger (*) problems a bulk of single/multi-threaded/whatever_other_configured libraries. So my next wish was to reduce the diversity. I deleted the stage directory and went on.. The doc states the usage of thread flags (-mt) but I was unable to set up a command line intuitively to build only multi-threaded release versions. One (!) example line should provide a recipe to solve this problem. I guess this is possible, after looking in Boost.Build. The next point is, I need in fact only the BGL. So I tried: v:\src\boost_1_32_0>bjam "-sTOOLS=msvc" --with-graph stage --------------------------------------------------------------------- skipping Boost.Python library build due to missing or incorrect configuration couldn't find Python.h in "c:/tools/python/include" You can configure the location of your python installation by setting: PYTHON_ROOT - currently "c:/tools/python" PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. "2.2", NOT "2.2.1") - currently "2.2" The following are automatically configured from PYTHON_ROOT if not otherwise set: PYTHON_LIB_PATH - path to Python library object; currently "c:/tools/python/libs" --------------------------------------------------------------------- don't know how to make stage ...found 1 target... ...can't find 1 target... v:\src\boost_1_32_0> I dont't know, if the python configuration/message is really necessary. Maybe an existing python installation can be found (I have an ActivePython here). But the the last 3 lines are completely meaningless. What shall I do with it ? A command line error ? A problem with graph's dependencies ? Something else ? msvc specific: The library as a heavily template-loaded piece of software should IMO suppress warning 4786 at least in their own implementation files. This makes it easier to spot errors during the installation run. Generally I lack information regarding dependencies for the single libraries. This should be part of the documentation (a must IMO, some accentuated doxygen graphs for the include hierarchy would be very helpful). Boost contains so many different things, and many people don't need all this stuff. It was absolutely no problem in the past, to install BGL (or its predecessor) by simply copying the header (neglecting for the moment the graphviz) interface. IMO, this should be possible further on, maybe some additional helper like iterator. But it should be documented ! Many people prefer lightwight libraries and it seems also current versions of boost _can_ be configured this way (with som acceptable manual adjusting). So a bit emphasis on these things yet in the doumentations "Getting started" section at a would be a nice thing (tm) and raise the libraries acceptance for new users. (*) ...failed updating 24 targets... ...skipped 48 targets... ...updated 1051 targets... Micha --
Micha Bieber wrote:
Hi, group
After some years staying away from boost, I installed the 1.32 release. The system was WinXP with VC6. I used the .exe variant. Take the following as remarks from an innocent, also if some of the issues seem to be trivial. Even though, I'm a C++ developer for more than 10 years now. I have used literally thousends of programs and libraries and I know, how quickly someone decides to skip the usage of software completely, simply because the installation becomes too strenous.
Probably you are not that experienced with c++, mayby c only?.. My experience is about 2 years in programming and ~1y in c++ and I had 0 problems installing and using boost on winxp & freebsd. At least if you that experienced you should know that there better versions of vc around for years and it's probably time to check them - with vc6 many boost libs don't compile (libs are ok, compiler can't handle them)
The story:
The exe is in fact an archive. This should be stated, because it suggests some form of installer.
Starting with bjam "-sTOOLS=msvc" stage first of all I got without bigger (*) problems a bulk of single/multi-threaded/whatever_other_configured libraries. So my next wish was to reduce the diversity. I deleted the stage directory and went on.. The doc states the usage of thread flags (-mt) but I was unable to set up a command line intuitively to build only multi-threaded release versions. One (!) example line should provide a recipe to solve this problem. I guess this is possible, after looking in Boost.Build. The next point is, I need in fact only the BGL. So I tried:
Looking inside my lib directory I don't see any libs/dlls for BGL. Probably you can use it as-is without compilation as many other parts of the boost lib. Anyway EVERYTHING is explained really well for starters, just read the manual
v:\src\boost_1_32_0>bjam "-sTOOLS=msvc" --with-graph stage --------------------------------------------------------------------- skipping Boost.Python library build due to missing or incorrect configuration
couldn't find Python.h in "c:/tools/python/include"
You can configure the location of your python installation by setting: PYTHON_ROOT - currently "c:/tools/python" PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. "2.2", NOT "2.2.1") - currently "2.2"
The following are automatically configured from PYTHON_ROOT if not otherwise set:
PYTHON_LIB_PATH - path to Python library object; currently "c:/tools/python/libs" --------------------------------------------------------------------- don't know how to make stage ...found 1 target... ...can't find 1 target...
v:\src\boost_1_32_0>
I dont't know, if the python configuration/message is really necessary. Maybe an existing python installation can be found (I have an ActivePython here). But the the last 3 lines are completely meaningless. What shall I do with it ? A command line error ? A problem with graph's dependencies ? Something else ?
You should read docs and it's enough to overcome this problem...
msvc specific: The library as a heavily template-loaded piece of software should IMO suppress warning 4786 at least in their own implementation files. This makes it easier to spot errors during the installation run.
Generally I lack information regarding dependencies for the single libraries. This should be part of the documentation (a must IMO, some accentuated doxygen graphs for the include hierarchy would be very helpful). Boost contains so many different things, and many people don't need all this stuff. It was absolutely no problem in the past, to install BGL (or its predecessor) by simply copying the header (neglecting for the moment the graphviz) interface. IMO, this should be possible further on, maybe some additional helper like iterator. But it should be documented ! Many people prefer lightwight libraries and it seems also current versions of boost _can_ be configured this way (with som acceptable manual adjusting). So a bit emphasis on these things yet in the doumentations "Getting started" section at a would be a nice thing (tm) and raise the libraries acceptance for new users.
(*) ...failed updating 24 targets... ...skipped 48 targets... ...updated 1051 targets...
Here's everything seems to be ok (if you use vc6 ;) You could try vs 2003 or vc++ 2005.
Micha --
Hallo pps, Wednesday, April 6, 2005, 5:01:10 PM, you wrote: p> Probably you are not that experienced with c++, mayby c only?.. My p> experience is about 2 years in programming and ~1y in c++ and I had 0 p> problems installing and using boost on winxp & freebsd. At least if you p> that experienced you should know that there better versions of vc around p> for years and it's probably time to check them - with vc6 many boost p> libs don't compile (libs are ok, compiler can't handle them) [...] p> Anyway EVERYTHING is explained really well for starters, just read the p> manual [...] p> You should read docs and it's enough to overcome this problem... I think, we talk about different things. I'm not to lazy to read the docs, I'm also able to fiddle out the things in the end. It was in no my intention to boast about my experience. I'm using all the other compilers too etc., etc. The newest one isn't always the best for me. VC6 is sufficient for many things. I'm not in need to use partial template specialization for every project. What I'm talking about, is the picture for someone completely new to the library and the first impression he has. And here I miss some things. RTFM is not the answer to all things, if I can make my manual better. A library is for use. I'm completely aware of the fact, that boost isn't finished. Laying all the development issues aside, there is also the smootheness when dealing with other aspects e.g. installation. BTW, its most of the time also a substantial hint to the inherent structure of software, if it doesn't feel neat from outside. It's a thing like the relationship between formulas and Paul Dirac. Personally I find the spectrum for boost a bit too broad, and splitting a library, new merging at a different level, splitting again etc. are completely common stages in software development (see Qt for a current example). I would like signalize this impression to someone, feeling responsible for these things, because I come - almost - from the outside, regarding boost, but surely not C++. Developer notoriously ignore these things. I know it, I'm a developer. But after some more years in the business, these things become more valuable to you. Thats, what experience really provides you with .. ;-) Micha --
Micha Bieber
Hallo pps,
Wednesday, April 6, 2005, 5:01:10 PM, you wrote: p> Probably you are not that experienced with c++, mayby c only?.. My p> experience is about 2 years in programming and ~1y in c++ and I had 0 p> problems installing and using boost on winxp & freebsd. At least if you p> that experienced you should know that there better versions of vc around p> for years and it's probably time to check them - with vc6 many boost p> libs don't compile (libs are ok, compiler can't handle them)
[...]
p> Anyway EVERYTHING is explained really well for starters, just read the p> manual
[...]
p> You should read docs and it's enough to overcome this problem...
I think, we talk about different things. I'm not to lazy to read the docs, I'm also able to fiddle out the things in the end. It was in no my intention to boast about my experience. I'm using all the other compilers too etc., etc. The newest one isn't always the best for me. VC6 is sufficient for many things. I'm not in need to use partial template specialization for every project. What I'm talking about, is the picture for someone completely new to the library and the first impression he has. And here I miss some things. RTFM is not the answer to all things, if I can make my manual better. A library is for use. I'm completely aware of the fact, that boost isn't finished. Laying all the development issues aside, there is also the smootheness when dealing with other aspects e.g. installation.
You should first know that we recognize that installation is still harder than it should be, and we're working on solutions. You should also know that vc6 support is, for most purposes, being dropped from Boost.Graph. You should also know that no build step is required for Boost.Graph, as prominently described in http://www.boost.org/libs/graph/doc/index.html under "How to Build the BGL." HTH, -- Dave Abrahams Boost Consulting www.boost-consulting.com
Micha Bieber wrote:
Hallo pps,
Wednesday, April 6, 2005, 5:01:10 PM, you wrote: p> Probably you are not that experienced with c++, mayby c only?.. My p> experience is about 2 years in programming and ~1y in c++ and I had 0 p> problems installing and using boost on winxp & freebsd. At least if you p> that experienced you should know that there better versions of vc around p> for years and it's probably time to check them - with vc6 many boost p> libs don't compile (libs are ok, compiler can't handle them)
[...]
p> Anyway EVERYTHING is explained really well for starters, just read the p> manual
[...]
p> You should read docs and it's enough to overcome this problem...
I think, we talk about different things. I'm not to lazy to read the docs, I'm also able to fiddle out the things in the end. It was in no my intention to boast about my experience. I'm using all the other compilers too etc., etc. The newest one isn't always the best for me. VC6 is sufficient for many things. I'm not in need to use partial template specialization for every project.
What I'm talking about, is the picture for someone completely new to the library and the first impression he has. And here I miss some things. RTFM is not the answer to all things, if I can make my manual better. A library is for use. I'm completely aware of the fact, that boost isn't finished. Laying all the development issues aside, there is also the smootheness when dealing with other aspects e.g. installation. BTW, its most of the time also a substantial hint to the inherent structure of software, if it doesn't feel neat from outside. It's a thing like the relationship between formulas and Paul Dirac. Personally I find the spectrum for boost a bit too broad, and splitting a library, new merging at a different level, splitting again etc. are completely common stages in software development (see Qt for a current example). I would like signalize this impression to someone, feeling responsible for these things, because I come - almost - from the outside, regarding boost, but surely not C++. Developer notoriously ignore these things. I know it, I'm a developer. But after some more years in the business, these things become more valuable to you. Thats, what experience really provides you with .. ;-)
I also used MANY libraries becase my c experience is larger than my c++ :), and I really feel that boost library is one of the best libs around and it's not "..boost isn't finished...". It's work in progress and every release version is quite finished product. It's difficult to compare boost to qt (in my opinion) becase qt is related to some particular domain (gui etc) however it has many thing in it but all of them are interconnected. Boost is an umbrella of very useful libraries http://boost.org/libs/libraries.htm (so, boost is a collection of libs, and qt is a framework) and boost libraries do not necessarily have any dependencies between each other. What do you mean by splitting library etc..?? I personally find boost bo be a very neatly packaged library. I'm sure after you get yourself familiar with boost you'll change your opinion.
Micha
pps
I also used MANY libraries becase my c experience is larger than my c++ :), and I really feel that boost library is one of the best libs around and it's not "..boost isn't finished...". It's work in progress and every release version is quite finished product.
While that's true, it's also true that we have work to do in the ease-of-use department.
It's difficult to compare boost to qt (in my opinion) becase qt is related to some particular domain (gui etc) however it has many thing in it but all of them are interconnected. Boost is an umbrella of very useful libraries http://boost.org/libs/libraries.htm (so, boost is a collection of libs, and qt is a framework) and boost libraries do not necessarily have any dependencies between each other. What do you mean by splitting library etc..?? I personally find boost bo be a very neatly packaged library. I'm sure after you get yourself familiar with boost you'll change your opinion.
We could do a lot better with packaging, but we're working on it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
p> It's difficult to compare boost to qt (in my opinion) becase qt is p> related to some particular domain (gui etc) however it has many thing in p> it but all of them are interconnected. Boost is an umbrella of very p> useful libraries http://boost.org/libs/libraries.htm (so, boost is a p> collection of libs, and qt is a framework) The differences are correct. But there are common things also - true for almost every software. Especially, if you have used boost some years ago and now again, you will see that the level of integration has been raised. That also means the concept of 'merging' I'm alluding to. IIRC, the intention was to have a bundle of headers with template code inside and thats all. Nowadays the intention might be the same but you have more components depending on compilation etc.. On the other hand, it seems (have not yet grasped completely the libraries current state at this level) many components are still very loosely (good thing!) coupled. My wish was simply, to make this transparent and as simple to use as possible for the user. Documentation is helpful (and relatively cheap in this case) here. A static html page with a dependence graph and links to compiled versions of bcp (in order to create the adequate file structure for this graph) might be useful in this context. Laterly a full-featured installer could adopt the bcp part or parallel it. Also a survey which library is 'pure templatized' which not, which 'pure' depending on particular features etc. would be helpful. Of course, these informations are partly in the docs for the single libraries my emphasis here is on survey. BTW, for every developer dealing with these things it causes a look regarding the big picture, what generally is a good thing also for the development .. Just my 2 cent, Micha --
Micha Bieber
Personally I find the spectrum for boost a bit too broad, and splitting a library, new merging at a different level, splitting again etc. are completely common stages in software development (see Qt for a current example).
I'm not quite sure what you're getting at, but does http://www.boost.org/tools/bcp/bcp.html begin to address your concern? -- Dave Abrahams Boost Consulting www.boost-consulting.com
DA> http://www.boost.org/tools/bcp/bcp.html begin to address your concern? It looks really helpful. Thank you and also Pablo, who mentioned the tool first. BTW, if you look for a recommendable Windows installer: http://nsis.sourceforge.net/ It's likely you're aware of it yet. Micha --
Micha Bieber wrote:
DA> http://www.boost.org/tools/bcp/bcp.html begin to address your concern?
It looks really helpful. Thank you and also Pablo, who mentioned the tool first.
BTW, if you look for a recommendable Windows installer:
nsis is good but it's windows only (just as winamp)
It's likely you're aware of it yet.
Micha
"Micha Bieber"
--------------------------------------------------------------------- skipping Boost.Python library build due to missing or incorrect configuration
couldn't find Python.h in "c:/tools/python/include"
You can configure the location of your python installation by setting: PYTHON_ROOT - currently "c:/tools/python" PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. "2.2", NOT "2.2.1") - currently "2.2"
The following are automatically configured from PYTHON_ROOT if not otherwise set:
PYTHON_LIB_PATH - path to Python library object; currently "c:/tools/python/libs" --------------------------------------------------------------------- don't know how to make stage ...found 1 target... ...can't find 1 target...
v:\src\boost_1_32_0>
I dont't know, if the python configuration/message is really necessary. Maybe an existing python installation can be found (I have an ActivePython here). But the the last 3 lines are completely meaningless. What shall I do with it ? A command line error ? A problem with graph's dependencies ? Something else ?
It might be useful to know that, every lib that requires building, has it's own build subdirectory in libs\<lib you want>\build, which builds it by itself and skips the rest of boost. AIUI you tried building all of boost.
msvc specific: The library as a heavily template-loaded piece of software should IMO suppress warning 4786 at least in their own implementation files. This makes it easier to spot errors during the installation run.
Generally I lack information regarding dependencies for the single libraries. This should be part of the documentation (a must IMO, some accentuated doxygen graphs for the include hierarchy would be very helpful). Boost contains so many different things, and many people don't need all this stuff. It was absolutely no problem in the past, to install BGL (or its predecessor) by simply copying the header (neglecting for the moment the graphviz) interface. IMO, this should be possible further on, maybe some additional helper like iterator. But it should be documented ! Many people prefer lightwight libraries and it seems also current versions of boost _can_ be configured this way (with som acceptable manual adjusting). So a bit emphasis on these things yet in the doumentations "Getting started" section at a would be a nice thing (tm) and raise the libraries acceptance for new users.
Though I've not even tried it and don't know if it's really working, this tool might be what you're looking for: http://www.boost.org/tools/bcp/bcp.html
(*) ...failed updating 24 targets... ...skipped 48 targets... ...updated 1051 targets...
Micha --
HTH Pablo Aguilar
participants (4)
-
David Abrahams -
Micha Bieber -
Pablo Aguilar -
pps