- Boost - lists.boost.org

msvc-tools
by Victor A. Wagner Jr. 13 Jun '05

13 Jun '05

I changed the /EHsc to /EHac which seems to affect none of the tests excep the errors test on VC-8_0 which now works I've tested it with 7.1 and 8.0 I don't have any other complers btw, why is the /EHac (now) put in the command line twice? once as part of CFLAGS and once directly?? I just started another regression test....I'll be back before it finishes Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

logging library - minor bug report in "$yy" year formating
by Andy Schweitzer 13 Jun '05

13 Jun '05

Hello there, been playing with the logging library. Is this the right place to post bug reports? It seems that $yy prints "105" for the year 2005, not "05", which I expected. $yyyy is correct, it prints 2005. If line 173, // vals[m_yy + 1] = details.tm_year; is changed to // vals[m_yy + 1] = details.tm_year % 100; it appears to work... although I only tested with today's date.

2 1

logging library - v1.3.3
by John Torjo 13 Jun '05

13 Jun '05

Hi all, Just included the nifty appenders from Caleb, and made some small fixes. Enjoy! http://torjo.com/code/logging-v133.zip Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -v1.6.3 (Resource Splitter) -- http://www.torjo.com/cb/ - Click, Build, Run!

2 2

IR is using boost
by Andrew Cameron 13 Jun '05

13 Jun '05

Name: PROGNOSIS IP Telephony Manager IP Telephony Express Company: Integrated Research P/L Description: PROGNOSIS is a suite of IP telephony management software products, specifically designed to address the key challenges of IP telephony life cycle management, including network-readiness, assessment, pre-deployment assurance testing, and ongoing Day-2 management of Cisco CallManager, Cisco Unity, and Cisco AVVID infrastructure. Boost Libs: boost.any boost.bind boost.function boost.lexical_cast boost.mpl boost.numeric_cast boost.ref boost.regex boost.smart_ptr boost.thread boost.thread_pool boost.type_traits URL: http://www.ir.com _____________________________________________________________________ This email is intended only for the use of the individual or entity named above and may contain information that is confidential and/or privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this Email is strictly prohibited. If you have received this Email in error, please notify us immediately by return email or telephone +61 2 9966 1066 and destroy the original message. Thank You _______________________________________________________________________

1 0

Help setting up boost for vc7
by Chris Ward 13 Jun '05

13 Jun '05

I have MS VC++ 7.1 installed to the default location (C:\Program Files\Microsoft Visual Studio .NET 2003), O/S WinXPSP2 However, when I run Build.bat from the command line, it returns " \Utilities\Bin\x86 was unexpected at this time." This occurs if I let the script auto-detect and also if I specify the toolset as vc7. Can someone please steer me in the right direction? regards Chris Ward

3 2

[thread] null_mutex
by Jody Hagins 13 Jun '05

13 Jun '05

Looking through the archives, a number of requests have been made for a null_mutex, but none exist. Probably because of the chance of trouble when used in conjunction with a condition variable. However, I have need for one (and it looks like others do as well, with a simple google search). Attached, are two files, each representing the output of running cvs diff on my local CVS repository (which is the official 1.32 release). diff.txt is the result of running: cvs -q diff diff-c.txt is the result of running: cvs -q diff -c I'd appreciate any feedback, and also consideration to add something like this to Boost.Thread.

5 12

Re: [boost] Pheonix-2 Debut
by Brian Braatz 12 Jun '05

12 Jun '05

> Super! How about the adaptable closures? I have to warn you though > that this may be a temporary bridge for Spirit 1.8 to Spirit 2.0. > Adaptable closures support may be retired in place of true local > variables (already supported in Phoenix 2); unless a solution > can be found to get rid of the nasty TLS ugliness in multithreaded > code. > > Regards, > -- > Joel de Guzman [Brian Braatz Writes:] If you would permit indulging my curiosity: :) I understand TLS. But I don't understand your problem? Is the problem because you need to use a global or static and when do you so, you are not thread safe (i.e. the classic getlasterror() problem with threads)?

2 1

[boostbook] building failed
by pedro.lamarao＠mndfck.org 12 Jun '05

12 Jun '05

With current CVS HEAD, following the instructions in the documentation, I get the following error. I tried reading the various Jamfile.v2 all over the place to try and understand what exactly I must pass to xsltproc to produce documentation manually but have had little success so far. [pedro@localhost doc]$ bjam-cvs --v2 Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (and if you don't know what ICU is then you probably don't need it). warning: Python location is not configured warning: the Boost.Python library won't be built warning: no toolsets are configured. warning: you won't be able to build C++ programs. warning: please consult the documentation. /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:1259: in construct from module object(typed-target)@8 error: unable to construct ../libs/program_options/build/boost_program_options /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:1142: in object(typed-target)(a)8.generate from module object(typed-target)@8 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:757: in generate-really from module object(main-target)@10 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:730: in object(main-target)(a)10.generate from module object(main-target)@10 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:886: in targets.generate-from-reference from module targets /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:1080: in generate-dependencies from module object(typed-target)@24 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:1121: in object(typed-target)(a)24.generate from module object(typed-target)@24 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:757: in generate-really from module object(main-target)@7 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:730: in object(main-target)(a)7.generate from module object(main-target)@7 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/tools/quickbook.jam:186: in object(quickbook-binary-generator)(a)1.run from module object(quickbook-binary-generator)@1 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/generators.jam:819: in try-one-generator-really from module generators /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/generators.jam:866: in try-one-generator from module generators /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/generators.jam:1073: in construct-really from module generators /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/generators.jam:1132: in generators.construct from module generators /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:1256: in construct from module object(typed-target)@22 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:1142: in object(typed-target)(a)22.generate from module object(typed-target)@22 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:757: in generate-really from module object(main-target)@5 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:730: in object(main-target)(a)5.generate from module object(main-target)@5 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:886: in targets.generate-from-reference from module targets /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:1080: in generate-dependencies from module object(typed-target)@19 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:1118: in object(typed-target)(a)19.generate from module object(typed-target)@19 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:757: in generate-really from module object(main-target)@1 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:730: in object(main-target)(a)1.generate from module object(main-target)@1 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build/targets.jam:252: in object(project-target)(a)16.generate from module object(project-target)@16 /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/build-system.jam:196: in load from module build-system /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/kernel/modules.jam:259: in import from module modules /home/pedro/Workspace/boost/boost_HEAD/tools/build/v2/kernel/bootstrap.jam:153: in boost-build from module /home/pedro/Workspace/boost/boost_HEAD/boost-build.jam:12: in module scope from module

2 2

Re: [boost] Boost Build Env Checker (was RE: Re: CustomerFriendlierBoost Installation)
by Brian Braatz 12 Jun '05

12 Jun '05

> -----Original Message----- > On Behalf Of David Abrahams > > "Brian Braatz" <brianb(a)rmtg.com> writes: > > [Brian Braatz Writes:] > > My plan (to address this organically): > > * First off finish my other work :) > > * then spend the time to really get my head wrapped around bjam\boost > > build > > * debug my own build problems- and make careful notes on "what the > > problems were" > > * Post-Mortem- build a tool that WOULD have shown me the problem > > immediately. I.e. (weak example:) if my bjam.exe is the wrong version- > > then the tool would simply report the version > [David Abrahams Writes:] > Again, shouldn't bjam itself just do this? It would be easy for > Boost.Build to know what version of bjam it requires and complain if > bjam is not up-to-date. [Brian Braatz Writes:] Yes. After reviewing your mail and bjam\bulid a bit more- I think I am starting to "see it" (Bjam\Build). My guess is, whatever the final solution ends up being will be something connected at the lower levels to either bjam or build. Also my example was "weak". :)- It's probably easier to talk about specific problems once I have identified the actual CAUSES of (to start with) my problems. > > > * share the tool with the rest of the community. > > * watch the users list for folks having build problems- offer to help > > them- use the tool as a proxy for figuring out their problems- in this > > way the tool evolves the ability to solve the common problems. OR it > > becomes clearly proven that this is not possible. (my gut tells me it IS > > possible) > > * I am going to save this mail off, and then when I have learned a few > > things by doing above, I may "re-open" this thread with what I have > > learned. > > > > Thank you David for a very useful conversation. :) > [David Abrahams Writes:] > Sure thing. I hope it leads to useful tools! > [Brian Braatz Writes:] :)

1 0

Re: [boost] Boost Build Env Checker (was RE: Re: CustomerFriendlier Boost Installation)
by Brian Braatz 12 Jun '05

12 Jun '05

David, belated response- sorry for the disconnection in time. Let me say a (HUGE) THANK YOU for writing up below, it really has my gears turning. I have been reviewing your mail, and reviewing the boost build docs contemplating the issues you raised daily since your post. (thinking maybe if I "sleep on it" a solution will appear). Where I am at: * I see what you are saying * I am left still feeling like this is a solvable problem * Yes, you are right there is no clear and easy path that we can see right now * Before I die (grin- I am on a mission :) ), I will do something to enable debugging of build problems. There IS a solution, one just have to think about it long enough until they find it :) What I am thinking right now: * I would appear to have more bjam\boost build problems than most people :) * I need to be careful, because I have a tendency to try to do too many things at once. (right now I am working to finish a preview of a potential boost library). * I need to remember that trying to think about this from the top down, and "organically" growing a solution are two different things. My plan (to address this organically): * First off finish my other work :) * then spend the time to really get my head wrapped around bjam\boost build * debug my own build problems- and make careful notes on "what the problems were" * Post-Mortem- build a tool that WOULD have shown me the problem immediately. I.e. (weak example:) if my bjam.exe is the wrong version- then the tool would simply report the version * share the tool with the rest of the community. * watch the users list for folks having build problems- offer to help them- use the tool as a proxy for figuring out their problems- in this way the tool evolves the ability to solve the common problems. OR it becomes clearly proven that this is not possible. (my gut tells me it IS possible) * I am going to save this mail off, and then when I have learned a few things by doing above, I may "re-open" this thread with what I have learned. Thank you David for a very useful conversation. :) Brian > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of David Abrahams > Sent: Monday, June 06, 2005 5:18 AM > To: boost(a)lists.boost.org > Subject: [boost] Re: Boost Build Env Checker (was RE: Re: > CustomerFriendlier Boost Installation) > > "Brian Braatz" <brianb(a)rmtg.com> writes: > > > boost-bounces(a)lists.boost.org wrote: > >> On Behalf Of David Abrahams > >> Sent: Tuesday, May 31, 2005 7:08 AM > >> To: boost(a)lists.boost.org > >> Subject: [boost] Re: Customer Friendlier Boost Installation > >> > >> "Brian Braatz" <brianb(a)rmtg.com> writes: > >> > >> > HAVING said that here is the suggestion, reformed: > >> > > >> > Boostenvcheck.exe become s a program which LISTS the dependencies for > >> > your configuration. > >> > >> Can you show an example of what that output might look like? I don't > even > >> have a clear idea of what you mean by "dependencies" or "your > >> configuration." > > [Brian Braatz Writes:] > > > > I must say, I need to fully absorb how bjam \ boost.build interoperate, > > until doing so, please understand the details of this idea maybe ill > > formed. I get it conceptually, but it is still a "black box" in my head. > > > <snip example of non-Boost environment check> > > > when it says "passed"- I can quickly re-direct them back to their code. > > if they are not convinced, I can have them send me the report and I can > > look at it and try to determine where the issue is. > > Well, let's look at the dependencies for Boost. > > 1. Boost.Build v2 (I'm ignoring v1 as we're going to retire it) > > A. Boost.Jam > > I. bjam in the PATH, or > > II. The contents of tools/build/jam_src available with which to > build it. Should we check for every file? Just running the > bjam build procedure does that by itself; does it make sense > to build a redundant checker? > > B. The contents of tools/build/v2. Should we check for every file? > > C. Toolsets properly configured in user-config.jam and/or > site-config.jam. > > Default versions of these configuration files ship with > Boost.Build and are used unless the user supplies her own > versions, so there's nothing to check for. Boost.Build > itself is designed to detect when there are no toolsets > configured or when toolsets are configured improperly. > Should we really try to build a redundant checker? > > 2. The Boost header files for the libraries the user wants to use. > Should we check for every file? > > 3. The libs/whatever/src and libs/whatever/build directories for any > non-header-only libraries the user wants to use. Should we check > for every file? > > I can't think of anything else. So what, precisely, should we check > for, and what would the output look like if something were not found? > > > ADDTIIONAL scenario: > > > > Lets say, in my compiler business, I have a scenario where I > > occasionally release to the users a bug fixed header file. I send out a > > mail with the new file and explicit instructions on where to put it. > > > > After I have released a few bug fixed header files, I find users > > complaining about weird problems. Turns out, I am now back to spending > > an dreadful amount of time on the phone only to discover 9 times out of > > 10 the user did not follow instructions. 1 time out of 10 there actually > > was a bug in something I released. 10 times out of 10, the customer is > > frustrated. Even if the customer REALIZES THEY made the mistake, it > > still leaves them frustrated with ME and my PRODUCT. > > > > So I elect to get a bit more extreme in my env checker. > > > > I upgrade it so that it adds to the report a hash of all the "things it > > depends on", i.e. header files, link.exe etc. > > > > So now, when the user has a problem, I have them send me the report. I > > can also make available to them a list of the hashes for the files which > > I have tested to "work". > > > > I spend less time supporting my product, and my customers are happier > > because I can keep them running much more effectively. > > > > I have put a system in place to "Introspect" the users environment. By > > doing so, I have decreased the amount of time I have to spend > > introspecting manually. > > I understand the principle, but I don't understand how to apply it > effectively in our case. > > > HOW THIS RELATES TO BOOST.BUILD: > > I need to understand boost.buiid better to give a better suggestion. > > Hopefully my example might inspire the "Dependancies" to shake out, even > > if I do not fully understand boost.build yet. > > > > I believe this STYLE of thinking can be applied, but I have to get my > > current boost things done before I can start down this track. > > > > As I said before, if the thinking here inspires someone to START > > something like this all the better . :) > > > > IF NOT, I intend on tackling this in the future. (I first have to become > > a expert in boost.build though :)) > > I disagree. Understanding what the system depends on does not > require understanding all its internals. > > > I would like to eventually see something that allows someone to SPIT out > > a report, mail it to the list, and have the people on the list be able > > to IMMEDIATELY tell the person what could be horked, or why it is not > > building for them. > > That'd be great. The question is, what gets reported? > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1