From dave at boost-consulting.com Sat May 1 03:28:44 2004 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 30 Apr 2004 21:28:44 -0400 Subject: [C++-sig] Re: using map_indexing_suite: make_tuple ambiguous? References: Message-ID: Dave Berton writes: > I am trying to wrap a std::map<> using the map_indexing_suite<>, however > I am getting 'call of overloaded make_tuple() is ambiguous'. The The compiler is right. There's a bug in map_indexing_suite.hpp (or the C++ language definition; darned ADL again!) You should change line 95 from: return "(%s, %s)" % make_tuple(e.first, e.second); to return "(%s, %s)" % python::make_tuple(e.first, e.second); Joel, will you add Dave Berton's change to the test suite, then make this change in CVS and verify that it fixes things? Thanks! -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From dave at boost-consulting.com Sat May 1 03:24:13 2004 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 30 Apr 2004 21:24:13 -0400 Subject: [C++-sig] Re: Boost.Python and gcc 3.4 References: <1083253931.31481.110.camel@pbarbier> <200404291605.i3TG5Ci04544@libra3.slac.stanford.edu> Message-ID: "Paul F. Kunz" writes: > I get the following error message when running my Python module > after building everything (but Python) with gcc 3.4.0... Paul, Please see http://www.boost-consulting.com/boost/more/discussion_policy.htm#quoting on starting a new topic. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From linux_python_lover at yahoo.com Sat May 1 07:49:45 2004 From: linux_python_lover at yahoo.com (Junaid Ali) Date: Fri, 30 Apr 2004 22:49:45 -0700 (PDT) Subject: [C++-sig] lost sys.stderr Message-ID: <20040501054945.24465.qmail@web90101.mail.scd.yahoo.com> hello, ive tried to run Mozpython 0.1.1(source attached) on my i386 with Python 2.3.3 and Mozilla 1.6. While the program works perfectly well for windows , but when i try to run it on linux it gives me an error as "lost sys.stderr" I think the problem lies in the pythontohtmlconv module wherein the python script output is written mistakenly onto the standard o/p rather than the file. ny help is most welcome. Ali --------------------------------- Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MozPython-0.1.1_src.zip Type: application/x-zip-compressed Size: 107038 bytes Desc: MozPython-0.1.1_src.zip URL: From acorriga at cs.stevens-tech.edu Sat May 1 14:53:29 2004 From: acorriga at cs.stevens-tech.edu (Andrew Thomas Corrigan) Date: Sat, 1 May 2004 08:53:29 -0400 (EDT) Subject: [C++-sig] passing a unicode string from python to c++ std::wstring Message-ID: I asked about this a week ago with no reply. So I'm asking again since it seems to me like a major bug in boost python, which will ultimately force me to fix it myself, or abandon python. Has anyone ever succesfully passed to a c++ function, that expects a std::wstring, a unicode string that is longer than 7 characters? Is this a well known bug, that is already being taken care of? Andrew From dave at boost-consulting.com Sat May 1 16:37:43 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 01 May 2004 10:37:43 -0400 Subject: [C++-sig] Re: passing a unicode string from python to c++ std::wstring References: Message-ID: Andrew Thomas Corrigan writes: > I asked about this a week ago with no reply. So I'm asking again since > it seems to me like a major bug in boost python, which will ultimately > force me to fix it myself, or abandon python. > > Has anyone ever succesfully passed to a c++ function, that expects a > std::wstring, a unicode string that is longer than 7 characters? > > Is this a well known bug, that is already being taken care of? Yes, the standard Boost.Python regression tests do this: >>> rewrap_value_wstring(u'yo, wassup?') u'yo, wassup?' If there's a bug, how do you know it's not in your own code? If you think there's a bug in Boost.Python, you ought to be able to produce a very simple test case that will reproduce the problem. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From acorriga at cs.stevens-tech.edu Sat May 1 17:16:41 2004 From: acorriga at cs.stevens-tech.edu (Andrew Thomas Corrigan) Date: Sat, 1 May 2004 11:16:41 -0400 (EDT) Subject: [C++-sig] Re: passing a unicode string from python to c++ std::wstring In-Reply-To: References: Message-ID: > rewrap_value_wstring(u'yo, wassup?') Should I use that rewrap_value_wstring to make it not crash? > If there's a bug, how do you know it's not in your own code? I don't. It just seems that way. I say this because merely passing a string from python to c++ that is too long, will make it crash. I'll produce a simple test case ASAP. Andrew From acorriga at cs.stevens-tech.edu Sat May 1 18:40:25 2004 From: acorriga at cs.stevens-tech.edu (andrew) Date: Sat, 01 May 2004 12:40:25 -0400 Subject: [C++-sig] Re: passing a unicode string from python to c++ std::wstring In-Reply-To: References: Message-ID: <4093D2F9.5040009@cs.stevens-tech.edu> As I mentioned in an old thread, this is with MSVC 7, compiled in release mode, with boost_python.lib It wasn't as simple as just passing a string greater than 7 characters that made it crash. I was using a map in the functions where it crashed. But you'll see that something that works for a string with 7 characters, does not for a string with 8 characters. The simplest test case I could make: http://guinness.cs.stevens-tech.edu/~acorriga/boost/main.cpp http://guinness.cs.stevens-tech.edu/~acorriga/boost/test.py Output: http://guinness.cs.stevens-tech.edu/~acorriga/boost/output.jpg main.cpp compiled into a dll in case it saves you some time: http://guinness.cs.stevens-tech.edu/~acorriga/boost/abc.dll Thanks a lot! Andrew From linux_python_lover at yahoo.com Sat May 1 18:42:24 2004 From: linux_python_lover at yahoo.com (Ali) Date: Sat, 1 May 2004 09:42:24 -0700 (PDT) Subject: [C++-sig] lost sys.stderr Message-ID: <20040501164224.88740.qmail@web90108.mail.scd.yahoo.com> hello, ive tried to run Mozpython 0.1.1(source attached) on my i386 with Python 2.3.3 and Mozilla 1.6. While the program works perfectly well for windows , but when i try to run it on linux it gives me an error as "lost sys.stderr" I think the problem lies in the pythontohtmlconv module wherein the python script output is written mistakenly onto the standard o/p rather than the file. ny help is most welcome. Ali __________________________________ Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs http://hotjobs.sweepstakes.yahoo.com/careermakeover From dave at boost-consulting.com Sat May 1 19:46:35 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 01 May 2004 13:46:35 -0400 Subject: [C++-sig] Re: passing a unicode string from python to c++ std::wstring References: <4093D2F9.5040009@cs.stevens-tech.edu> Message-ID: andrew writes: > As I mentioned in an old thread, this is with MSVC 7, compiled in > release mode, with boost_python.lib > > It wasn't as simple as just passing a string greater than 7 characters > that made it crash. I was using a map in the functions where it > crashed. But you'll see that something that works for a string with 7 > characters, does not for a string with 8 characters. > > The simplest test case I could make: > http://guinness.cs.stevens-tech.edu/~acorriga/boost/main.cpp > http://guinness.cs.stevens-tech.edu/~acorriga/boost/test.py > > Output: > http://guinness.cs.stevens-tech.edu/~acorriga/boost/output.jpg > > main.cpp compiled into a dll in case it saves you some time: > http://guinness.cs.stevens-tech.edu/~acorriga/boost/abc.dll > > Thanks a lot! It must be something about your build; it works perfectly for me: bjam -sBUILD=debug-python -sTOOLS=vc7 --verbose-test foo ...found 2105 targets... ...updating 6 targets... vc-C++ c:\build\bin\boost\libs\python\user\foo_ext.pyd\vc7\debug-python\foo.obj foo.cpp vc-Link c:\build\bin\boost\libs\python\user\foo_ext.pyd\vc7\debug-python\foo_ext_d.pyd c:\build\bin\boost\libs\python\user\foo_ext.pyd\vc7\debug-python\foo_ext.lib Creating library c:\build\bin\boost\libs\python\user\foo_ext.pyd\vc7\debug-python\foo_ext.lib and object c:\build\bin\boost\libs\python\user\foo_ext.pyd\vc7\debug-python\foo_ext.exp execute-test c:\build\bin\boost\libs\python\user\foo.test\vc7\debug-python\foo.run 1 file(s) copied. ====== BEGIN OUTPUT ====== it works for 7 chars it works for 7 chars it works for 7 chars it works for 8 chars it works for 8 chars it works for 8 chars [5601 refs] EXIT STATUS: 0 ====== END OUTPUT ====== **passed** c:\build\bin\boost\libs\python\user\foo.test\vc7\debug-python\foo.test ...updated 6 targets... -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From user at example.net Sun May 2 00:41:33 2004 From: user at example.net (Dominic) Date: Sun, 02 May 2004 00:41:33 +0200 Subject: [C++-sig] Re: boost.python + mingw + msvc python In-Reply-To: <4073798E.2090806@fastmail.fm> References: <4073798E.2090806@fastmail.fm> Message-ID: <4094279D.6040000@example.net> Daniel Holth wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Have any of you used a mingw compiled Boost.Python to compile an > extension for MSVC python (the standard python.org python)? Yes, I've created a custom libpython23.a file with I think impdef or such from the free borland command line compiler and the dlltools from mingw. Then I set PYTHON_LIB_PATH to where I stored the libpython23.a and PYTHON_ROOT to the standard Python directory. Afterwards I used bjam -sTOOLS=gcc-nocygwin to build the example supplied with boost python. Since I used cygwin I had to recompile bjam before boost, because cygwin has different absolute path names. That's also the reason why the tests in the example failed. However if you manually copy the dll-files to the python src directory everything runs as expected. I've only compiled boost-python and it's dependencies. The supplied commands and path-names are recovered from memory and might be wrong. A similar route should also work with mingw. I wonder if there even is a difference between -mno-cygwin and plain mingw. Ciao, Dominic > I've had a pretty straightforwards experience using ming to compile > Boost.Python (on an XP box, sadly NOT cross compiled from a Linux > machine) making gcc libraries for various dlls, and I can compile the > extension itself. > > Unfortunately when I try to import the extension I get a vague sort of > 'dll not found' error. > > I know this is vague, I just would like to know if anyone has > succeeded in compiling a working Python+Boost.Python extension this > way. I'm trying to wrap ogg, vorbis and theora. > (http://dingoskidneys.com/oggpy/) > > Thanks, > > Daniel > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.4 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFAc3mOVh4W2pVfoMsRAo8UAKCFAmvreyuAe2Tw0kbo/NYY+tqYCgCgj8SH > ltTCEyTB4cAhaouFDOMeo/g= > =Zilu > -----END PGP SIGNATURE----- From gwl at u.washington.edu Sun May 2 03:23:13 2004 From: gwl at u.washington.edu (Graeme Lufkin) Date: Sat, 01 May 2004 18:23:13 -0700 Subject: [C++-sig] Re: bjam rules for building embedded applications In-Reply-To: References: Message-ID: <1083460992.22644.38.camel@tigger.graemily.org> Thanks for your comments. I'll get working on some tutorial changes as soon as I figure out the static/dynamic issue mentioned below. On Fri, 2004-04-30 at 22:49, c++-sig-request at python.org wrote: > > To build an embedded application, we will use the exe rule and an > > embedding template defined below. This template should get added to > > libs/python/build/Jamfile in the Boost sources. > > > > template embedded > > : boost_python #embedded needs static library, not dynamic > > Actually, using the dynamic library is fine, and probably neccessary > if you want to do the extending/embedding thing where some extension > modules you want to use are separately linked shared objects. The tutorial says that embedded apps need to use the static versions of both libpython and libboost_python. Is this no longer the case (or never was the case)? I definitely want to be able to do the extend/embed simultaneously trick, so I'll try using shared libraries everywhere. > > : ../../.. #boost headers > > this ties you to a particular relative location w.r.t Boost. > > Much better to write: > > @boost > > which puts the root path of the Boost project right there... oh, I see > later on that you seem to be putting this in python.jam, so a relative > path isn't so bad. I still think project-relative is better. Cool. > > $(BOOST_PYTHON_V2_PROPERTIES) #Python include/linking dirs > > That's wrong; it includes, among other things, > BOOST_PYTHON_DYNAMIC_LIB, which conflicts with the fact that > you happen to be using the static library. Looking at > libs/python/test/Jamfile I think $(PYTHON_PROPERTIES) is what you want > here. Why don't you just use that as your example? Ok. > > Some questions: If I've got several separate programs (either > > extending, or embedding) using this technique, then each one has their > > own version of libboost_python.[a|so] which seems rather wasteful. Is > > there a recommended way to use a libboost_python.[a|so] in a fixed > > location? That is, please provide a Jamfile entry to do this. > > I don't understand the question. You can link to the shared > boost_python by substituting boost_python for boost_python. Okay, let me explain some more. I'm building all my extend/embed projects outside the boost source tree. So the extension template builds a version of libboost_python.so in the project's bin directory, then links the extension/embedded app against this version of the library, correctly noticing when the Boost.Python sources have changed. Now suppose I have two separate projects, both external to the boost tree. The template entry in each Jamfile will ensure that each project builds its own version of libboost_python, which seems a bit wasteful. In particular, I like to move libboost_python.so out of the bin/boost/libs/python/build/libboost_python.so/gcc/release/etc.. tree of directories to somewhere a little easier to get to (e.g. ~/lib) that is in my LD_LIBRARY_PATH. Because I know when the Boost source changes (when I cvs update) I'm not so concerned with having each project make sure I'm using the latest version. I'd rather build the library once every time I update, place it somewhere convenient, and link against that version in my projects' Jamfiles. Does this help explain what I'm looking for? Because running bjam in $(BOOST_ROOT) generates several versions of libboost_python, those would be the ideal candidates for this process. Additionally, the Jamfile in $(BOOST_ROOT) has an install target that will place the headers and built libraries right where I want them. And because several versions (debug/threading/etc) get built, I should still be able to make design choices in each individual project's Jamfile (that is, use no-debug multithreading here, debug singlethreading over here). So ideally, I'd like to provide two templates (for both extensions and embeds) to use in Jam targets: the current one that builds a separate version of libboost_python for each project, and a new one that links against an external version of libboost_python, the location perhaps controlled by a variable local to the projects' Jamfile. (And just in case it's not clear: I don't currently know how to write such a template, help would be appreciated) > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com Something new: I tried setting ALL_LOCATE_TARGET to a valid directory path in the Jamrules file, but it didn't do anything. The example Jamrules file has it commented out, has it ever been tried? I find extracting the library/executable from the deep tree of directories that bjam creates to be quite annoying, so would love to take advantage of this feature (assuming I'm correctly understanding its purpose!). Thanks -- - Graeme Lufkin gwl at u.washington.edu This sentence does in fact not have the property it claims not to have. From dave at boost-consulting.com Sun May 2 15:41:31 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 02 May 2004 09:41:31 -0400 Subject: [C++-sig] Re: bjam rules for building embedded applications References: <1083460992.22644.38.camel@tigger.graemily.org> Message-ID: Graeme Lufkin writes: [Please try to leave a blank line between quoted text and your reply] > Thanks for your comments. I'll get working on some tutorial changes as > soon as I figure out the static/dynamic issue mentioned below. Thanks; it's much appreciated. > On Fri, 2004-04-30 at 22:49, c++-sig-request at python.org wrote: > >> > To build an embedded application, we will use the exe rule and an >> > embedding template defined below. This template should get added to >> > libs/python/build/Jamfile in the Boost sources. >> > >> > template embedded >> > : boost_python #embedded needs static library, not dynamic >> >> Actually, using the dynamic library is fine, and probably neccessary >> if you want to do the extending/embedding thing where some extension >> modules you want to use are separately linked shared objects. > > The tutorial says that embedded apps need to use the static versions of > both libpython and libboost_python. Is this no longer the case (or > never was the case)? Never was. >> > Some questions: If I've got several separate programs (either >> > extending, or embedding) using this technique, then each one has their >> > own version of libboost_python.[a|so] which seems rather wasteful. Is >> > there a recommended way to use a libboost_python.[a|so] in a fixed >> > location? That is, please provide a Jamfile entry to do this. >> >> I don't understand the question. You can link to the shared >> boost_python by substituting boost_python for >> boost_python. > > Okay, let me explain some more. I'm building all my extend/embed > projects outside the boost source tree. So the extension template > builds a version of libboost_python.so in the project's bin directory, > then links the extension/embedded app against this version of the > library, correctly noticing when the Boost.Python sources have changed. > Now suppose I have two separate projects, both external to the boost > tree. The template entry in each Jamfile will ensure that each project > builds its own version of libboost_python, which seems a bit > wasteful. Why do you think it will do that? Normally, targets are built into a bin/... tree below the location of their Jamfiles. If you set ALL_LOCATE_TARGET=/some/path then all targets will be built into a single build tree rooted at /some/path/bin. Either way, there's a single Jamfile where libboost_python is defined so you won't get duplication. > In particular, I like to move libboost_python.so out of the > bin/boost/libs/python/build/libboost_python.so/gcc/release/etc.. tree of > directories to somewhere a little easier to get to (e.g. ~/lib) that is > in my LD_LIBRARY_PATH. Because I know when the Boost source changes > (when I cvs update) I'm not so concerned with having each project make > sure I'm using the latest version. I'd rather build the library once > every time I update, place it somewhere convenient, and link against > that version in my projects' Jamfiles. Does this help explain what I'm > looking for? Yep. > Because running bjam in $(BOOST_ROOT) generates several > versions of libboost_python, those would be the ideal candidates for > this process. So you can move those, and replace boost_python with the appropriate ... and ... options. > Additionally, the Jamfile in $(BOOST_ROOT) has an install > target that will place the headers and built libraries right where I > want them. And because several versions (debug/threading/etc) get > built, I should still be able to make design choices in each individual > project's Jamfile (that is, use no-debug multithreading here, debug > singlethreading over here). > So ideally, I'd like to provide two templates (for both extensions and > embeds) to use in Jam targets: the current one that builds a separate > version of libboost_python for each project, Well, it doesn't, but... > and a new one that links > against an external version of libboost_python, the location perhaps > controlled by a variable local to the projects' Jamfile. (And just in > case it's not clear: I don't currently know how to write such a > template, help would be appreciated) I guess it mostly comes down to using library_name and path/to/search/for/libs. >> -- >> Dave Abrahams >> Boost Consulting >> http://www.boost-consulting.com > > Something new: I tried setting ALL_LOCATE_TARGET to a valid directory > path in the Jamrules file, but it didn't do anything. The example > Jamrules file has it commented out, has it ever been tried? I certainly use that feature all the time, although I set it in my environment. There were a few weeks when it was broken, but AFAIK Rene fixed it again before 1.31.0. > I find extracting the library/executable from the deep tree of > directories that bjam creates to be quite annoying, so would love to > take advantage of this feature (assuming I'm correctly understanding > its purpose!). Well, maybe you're not. It doesn't make the tree any less deep; it just unwinds the tree from the build tree (the one containing the Jamfiles). -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From linux_python_lover at yahoo.com Sun May 2 19:09:29 2004 From: linux_python_lover at yahoo.com (Ali) Date: Sun, 2 May 2004 10:09:29 -0700 (PDT) Subject: [C++-sig] Mozpython Help Message-ID: <20040502170929.13447.qmail@web90109.mail.scd.yahoo.com> hello, ive tried to run Mozpython 0.1.1(source attached) on my i386 with Python 2.3.3 and Mozilla 1.6. While the program works perfectly well for windows , but when i try to run it on linux it gives me an error as "lost sys.stderr" I think the problem lies in the pythontohtmlconv module wherein the python script output is written mistakenly onto the standard o/p rather than the file. ny help is most welcome. Ali --------------------------------- Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at boost-consulting.com Sun May 2 21:20:37 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 02 May 2004 15:20:37 -0400 Subject: [C++-sig] Re: Mozpython Help References: <20040502170929.13447.qmail@web90109.mail.scd.yahoo.com> Message-ID: Ali writes: > hello, > > ive tried to run Mozpython 0.1.1(source attached) There's no source attached. > on my i386 with > Python 2.3.3 and Mozilla 1.6. While the program works perfectly well > for windows , but when i try to run it on linux it gives me an error > as "lost sys.stderr" I think the problem lies in the > pythontohtmlconv module wherein the python script output is written > mistakenly onto the standard o/p rather than the file. ny help is > most welcome. Ali Does this have anything to do with Python/C++ language binding? AFAICT you should be asking on some Mozilla or Python-specific list. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From linux_python_lover at yahoo.com Sun May 2 21:30:29 2004 From: linux_python_lover at yahoo.com (Ali) Date: Sun, 2 May 2004 12:30:29 -0700 (PDT) Subject: [C++-sig] Mozpython Help Message-ID: <20040502193029.96735.qmail@web90107.mail.scd.yahoo.com> hello, i've attached the source alongwith. the concept which i believe is causing problems is because of the python/C++ bindings wherein there is problem writing to the stdout, which has been modified to a file (this is done in the pythontohtml module of the source). Hence it prints lost sys.stderr on the default stdout. thanx for replying. Ali --------------------------------- Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs --------------------------------- Do you Yahoo!? Win a $20,000 Career Makeover at Yahoo! HotJobs -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: MozPython-0.1.1_src.zip Type: application/x-zip-compressed Size: 107038 bytes Desc: MozPython-0.1.1_src.zip URL: From dave at boost-consulting.com Mon May 3 00:38:47 2004 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 02 May 2004 18:38:47 -0400 Subject: [C++-sig] Re: Mozpython Help References: <20040502193029.96735.qmail@web90107.mail.scd.yahoo.com> Message-ID: Ali writes: > hello, > > i've attached the source alongwith. the concept which i believe is > causing problems is because of the python/C++ bindings wherein there > is problem writing to the stdout, which has been modified to a file > (this is done in the pythontohtml module of the source). Hence it > prints lost sys.stderr on the default stdout. thanx for replying. FYI, I won't be looking at this. It's not a Boost.Python thing and it's too big for me to debug. I bet most people around here will have the same reaction. I don't mean to be harsh; it's just my assessment. I suggest you try to debug it yourself with GDB. Sorry I don't have any better answers. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From roman.yakovenko at actimize.com Mon May 3 08:39:09 2004 From: roman.yakovenko at actimize.com (Roman Yakovenko) Date: Mon, 3 May 2004 09:39:09 +0300 Subject: [C++-sig] Re: passing a unicode string from python to c++std::wstring Message-ID: <2D89F6C4A80FA547BF5D5B8FDDD04523046B77@exchange.adrembi.com> I think that the problem is with wrong selected "runtime library" for abc.dll. It should be Multi-threaded (debug) DLL. Could you check whether it is your case? Roman > -----Original Message----- > From: David Abrahams [mailto:dave at boost-consulting.com] > Sent: Saturday, May 01, 2004 8:47 PM > To: c++-sig at python.org > Subject: [C++-sig] Re: passing a unicode string from python to > c++std::wstring > > > andrew writes: > > > As I mentioned in an old thread, this is with MSVC 7, compiled in > > release mode, with boost_python.lib > > > > It wasn't as simple as just passing a string greater than 7 > characters > > that made it crash. I was using a map in the functions where it > > crashed. But you'll see that something that works for a > string with 7 > > characters, does not for a string with 8 characters. > > > > The simplest test case I could make: > > http://guinness.cs.stevens-tech.edu/~acorriga/boost/main.cpp > > http://guinness.cs.stevens-tech.edu/~acorriga/boost/test.py > > > > Output: > > http://guinness.cs.stevens-tech.edu/~acorriga/boost/output.jpg > > > > main.cpp compiled into a dll in case it saves you some time: > > http://guinness.cs.stevens-tech.edu/~acorriga/boost/abc.dll > > > > Thanks a lot! > > It must be something about your build; it works perfectly for me: > > bjam -sBUILD=debug-python -sTOOLS=vc7 --verbose-test foo > ...found 2105 targets... > ...updating 6 targets... > vc-C++ > c:\build\bin\boost\libs\python\user\foo_ext.pyd\vc7\debug-pyth > on\foo.obj > foo.cpp > vc-Link > c:\build\bin\boost\libs\python\user\foo_ext.pyd\vc7\debug-pyth > on\foo_ext_d.pyd > c:\build\bin\boost\libs\python\user\foo_ext.pyd\vc7\debug-pyth > on\foo_ext.lib > Creating library > c:\build\bin\boost\libs\python\user\foo_ext.pyd\vc7\debug-pyth > on\foo_ext.lib and object > c:\build\bin\boost\libs\python\user\foo_ext.pyd\vc7\debug-pyth > on\foo_ext.exp > execute-test > c:\build\bin\boost\libs\python\user\foo.test\vc7\debug-python\foo.run > 1 file(s) copied. > ====== BEGIN OUTPUT ====== > it works for 7 chars > it works for 7 chars > it works for 7 chars > it works for 8 chars > it works for 8 chars > it works for 8 chars > [5601 refs] > > EXIT STATUS: 0 > ====== END OUTPUT ====== > **passed** > c:\build\bin\boost\libs\python\user\foo.test\vc7\debug-python\foo.test > ...updated 6 targets... > > -- > Dave Abrahams > Boost Consulting > http://www.boost-consulting.com > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > From acorriga at cs.stevens-tech.edu Mon May 3 14:07:34 2004 From: acorriga at cs.stevens-tech.edu (Andrew Corrigan) Date: Mon, 3 May 2004 08:07:34 -0400 (EDT) Subject: [C++-sig] Re: passing a unicode string from python to c++std::wstring In-Reply-To: <2D89F6C4A80FA547BF5D5B8FDDD04523046B77@exchange.adrembi.com> References: <2D89F6C4A80FA547BF5D5B8FDDD04523046B77@exchange.adrembi.com> Message-ID: > I think that the problem is with wrong selected "runtime library" > for abc.dll. It should be Multi-threaded (debug) DLL. > Could you check whether it is your case? That did it! Thank you! Andrew From joel at boost-consulting.com Tue May 4 05:11:55 2004 From: joel at boost-consulting.com (Joel de Guzman) Date: Tue, 04 May 2004 11:11:55 +0800 Subject: [C++-sig] Re: using map_indexing_suite: make_tuple ambiguous? In-Reply-To: References: Message-ID: <409709FB.6060708@boost-consulting.com> David Abrahams wrote: > The following message is a courtesy copy of an article > that has been posted to gmane.comp.python.c++ as well. > > Dave Berton writes: > > >>I am trying to wrap a std::map<> using the map_indexing_suite<>, however >>I am getting 'call of overloaded make_tuple() is ambiguous'. The > > > The compiler is right. There's a bug in map_indexing_suite.hpp (or > the C++ language definition; darned ADL again!) > > You should change line 95 from: > > return "(%s, %s)" % make_tuple(e.first, e.second); > > to > > return "(%s, %s)" % python::make_tuple(e.first, e.second); > > Joel, will you add Dave Berton's change to the test suite, then make > this change in CVS and verify that it fixes things? Done. I added a test and verified that everything works as expected. I'm having some CVS problems, however. I'll commit as soon as I find out why I'm getting these CVS errors. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net From dave at boost-consulting.com Tue May 4 13:02:10 2004 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 04 May 2004 07:02:10 -0400 Subject: [C++-sig] Re: using map_indexing_suite: make_tuple ambiguous? In-Reply-To: <409709FB.6060708@boost-consulting.com> (Joel de Guzman's message of "Tue, 04 May 2004 11:11:55 +0800") References: <409709FB.6060708@boost-consulting.com> Message-ID: Joel de Guzman writes: > David Abrahams wrote: > >> The following message is a courtesy copy of an article >> that has been posted to gmane.comp.python.c++ as well. >> Dave Berton writes: >> >>>I am trying to wrap a std::map<> using the map_indexing_suite<>, however >>>I am getting 'call of overloaded make_tuple() is ambiguous'. The >> The compiler is right. There's a bug in map_indexing_suite.hpp (or >> the C++ language definition; darned ADL again!) >> You should change line 95 from: >> return "(%s, %s)" % make_tuple(e.first, e.second); >> to >> return "(%s, %s)" % python::make_tuple(e.first, >> e.second); >> Joel, will you add Dave Berton's change to the test suite, then make >> this change in CVS and verify that it fixes things? > > Done. I added a test and verified that everything works as expected. > I'm having some CVS problems, however. I'll commit as soon as I find > out why I'm getting these CVS errors. If your CVS/Root files say cvs.boost.sourceforge.net you need to change them to say cvs.sourceforge.net. I posted a procedure that works in cygwin bash to the boost-devel list a few days ago. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com From joel at boost-consulting.com Tue May 4 13:19:31 2004 From: joel at boost-consulting.com (Joel de Guzman) Date: Tue, 04 May 2004 19:19:31 +0800 Subject: [C++-sig] Re: using map_indexing_suite: make_tuple ambiguous? In-Reply-To: References: <409709FB.6060708@boost-consulting.com> Message-ID: <40977C43.6020302@boost-consulting.com> David Abrahams wrote: > Joel de Guzman writes: > > >>David Abrahams wrote: >> >> >>>The following message is a courtesy copy of an article >>>that has been posted to gmane.comp.python.c++ as well. >>>Dave Berton writes: >>> >>> >>>>I am trying to wrap a std::map<> using the map_indexing_suite<>, however >>>>I am getting 'call of overloaded make_tuple() is ambiguous'. The >>> >>>The compiler is right. There's a bug in map_indexing_suite.hpp (or >>>the C++ language definition; darned ADL again!) >>>You should change line 95 from: >>> return "(%s, %s)" % make_tuple(e.first, e.second); >>>to >>> return "(%s, %s)" % python::make_tuple(e.first, >>>e.second); >>>Joel, will you add Dave Berton's change to the test suite, then make >>>this change in CVS and verify that it fixes things? >> >>Done. I added a test and verified that everything works as expected. >>I'm having some CVS problems, however. I'll commit as soon as I find >>out why I'm getting these CVS errors. > > > If your CVS/Root files say cvs.boost.sourceforge.net you need to > change them to say cvs.sourceforge.net. I posted a procedure that > works in cygwin bash to the boost-devel list a few days ago. Yeah, I realized that. It's been committed. -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net From james.gunn at communisis-dm.co.uk Tue May 4 16:47:06 2004 From: james.gunn at communisis-dm.co.uk (James Gunn) Date: Tue, 4 May 2004 15:47:06 +0100 Subject: [C++-sig] Redirecting PyErr_Print Message-ID: <7A7AACCC920AD511BF510090273C273003D6AFB3@CHORPCSRV001> *** Before acting on this e-mail or opening any attachment you are advised to read the disclaimer at the end of this e-mail *** Hi all, I've read a few of the previous posts with regard to redirecting the output of PyErr_Print but I've still not managed to do it yet. My problem is that I have a GUI-based app that makes calls to an embedded Python interpreter and I need to capture the output of errors...more specifically, I really really need to capture the output of Py_CompileString. I've tried to setup a pipe in a similar way to how Pierre Barbier de Reuille described in his post 08/04/2004 (Re:[C++-sig]how to get python exception information in c++?) but it gives me problems. It seems that nothing gets written to the pipe as calls to read it cause it to block/wait. Does anyone have any clues? Thanks in advance. James Gunn Software Developer --LongSig Computer Bureau Communisis DM Manston Lane Crossgates Leeds LS15 8AH Telephone +44 (0)113 225 5306 Fax +44 (0)113 225 5921 Email James.Gunn at communisis-dm.co.uk ********************************************************************** Please note: This e-mail and its attachments contain only the opinions of the sender and do not necessarily reflect the policy(s) of the communisis group in general. Employees of the communisis group are required not to make any defamatory statements and not to infringe or authorise any infringement of copyright or any other legal right by e-mail. Any such communication is therefore outside the scope of employment of the individual concerned. The communisis group will not accept any liability in respect of such a communication. Confidentiality: This e-mail and any attachments, together with their contents, are confidential unless otherwise explicitly stated in writing by the sender of this e-mail and are for the intended recipient only. If they have come to you in error you must not take any action in respect of them, which includes but is not limited to reproducing, sending or storing them, other than to notifying the sender immediately of the mistake, and deleting the e-mail, any attachments and any reproductions made by replying to it. Viruses: This e-mail and any attachments have been scanned for viruses but we cannot guarantee that they are virus free. The recipient should check this e-mail and any attachments for viruses. The communisis group accepts no responsibility for any damage caused by any virus transmitted by this e-mail or any of its attachments. In the event of any unauthorised copying or forwarding, the recipient will be required to indemnify the communisis group against any claim for loss or damage caused by any viruses or otherwise. ********************************************************************** ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierre.barbier at cirad.fr Tue May 4 17:17:08 2004 From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille) Date: Tue, 04 May 2004 17:17:08 +0200 Subject: [C++-sig] Redirecting PyErr_Print In-Reply-To: <7A7AACCC920AD511BF510090273C273003D6AFB3@CHORPCSRV001> References: <7A7AACCC920AD511BF510090273C273003D6AFB3@CHORPCSRV001> Message-ID: <1083683813.1525.5.camel@pbarbier> When you open a pipe for that, you have to be waiting in a reading state. If you are not, python will be blocked when trying to write. Depending on what exactly you want to do, you can just define a function that takes a string as argument and handle the string as you want the error strings to be handled. Then, export it to python and define a pseudo-file with its write method bound to this function. After, you'll have to replace sys.stderr by an instance of your pseudo class. It will work too ... It's done that way with most Python GUIs. Pierre Barbier de Reuille Le mar 04/05/2004 ? 16:47, James Gunn a ?crit : > *** Before acting on this e-mail or opening any attachment you are > advised to read the disclaimer at the end of this e-mail *** > > Hi all, > > I've read a few of the previous posts with regard to redirecting the > output of PyErr_Print but I've still not managed to do it yet. > My problem is that I have a GUI-based app that makes calls to an > embedded Python interpreter and I need to capture the output of > errors...more specifically, I really really need to capture the output > of Py_CompileString. > > I've tried to setup a pipe in a similar way to how Pierre Barbier de > Reuille described in his post 08/04/2004 (Re:[C++-sig]how to get > python exception information in c++?) but it gives me problems. It > seems that nothing gets written to the pipe as calls to read it cause > it to block/wait. > > Does anyone have any clues? > > Thanks in advance. > > James Gunn > Software Developer > --LongSig > > Computer Bureau > Communisis DM > Manston Lane > Crossgates > Leeds > LS15 8AH > > Telephone +44 (0)113 225 5306 > Fax +44 (0)113 225 5921 > Email James.Gunn at communisis-dm.co.uk > > > ********************************************************************** > Please note: This e-mail and its attachments contain only the opinions > of the sender and do not necessarily reflect the policy(s) of the > communisis group in general. > > Employees of the communisis group are required not to make any > defamatory statements and not to infringe or authorise any > infringement of copyright or any other legal right by e-mail. Any such > communication is therefore outside the scope of employment of the > individual concerned. The communisis group will not accept any > liability in respect of such a communication. > > Confidentiality: This e-mail and any attachments, together with their > contents, are confidential unless otherwise explicitly stated in > writing by the sender of this e-mail and are for the intended > recipient only. If they have come to you in error you must not take > any action in respect of them, which includes but is not limited to > reproducing, sending or storing them, other than to notifying the > sender immediately of the mistake, and deleting the e-mail, any > attachments and any reproductions made by replying to it. > > Viruses: This e-mail and any attachments have been scanned for viruses > but we cannot guarantee that they are virus free. The recipient should > check this e-mail and any attachments for viruses. The communisis > group accepts no responsibility for any damage caused by any virus > transmitted by this e-mail or any of its attachments. In the event of > any unauthorised copying or forwarding, the recipient will be required > to indemnify the communisis group against any claim for loss or damage > caused by any viruses or otherwise. > ********************************************************************** > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > ______________________________________________________________________ > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68 -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68 From james.gunn at communisis-dm.co.uk Tue May 4 17:23:00 2004 From: james.gunn at communisis-dm.co.uk (James Gunn) Date: Tue, 4 May 2004 16:23:00 +0100 Subject: [C++-sig] Redirecting PyErr_Print Message-ID: <7A7AACCC920AD511BF510090273C273003D6AFB5@CHORPCSRV001> Hi Pierre, Thanks for the quick response...it's ok now. I've managed to do it without creating a pipe. Instead I just use a simple OuputCatcher example that I found elsewhere and it works fine for me. Cheers, James. > -----Original Message----- > From: Pierre Barbier de Reuille [mailto:pierre.barbier at cirad.fr] > Sent: 04 May 2004 16:17 > To: Development of Python/C++ integration > Subject: Re: [C++-sig] Redirecting PyErr_Print > > > When you open a pipe for that, you have to be waiting in a > reading state. If you are not, python will be blocked when > trying to write. > > Depending on what exactly you want to do, you can just define > a function that takes a string as argument and handle the > string as you want the error strings to be handled. Then, > export it to python and define a pseudo-file with its write > method bound to this function. After, you'll have to replace > sys.stderr by an instance of your pseudo class. It will work > too ... It's done that way with most Python GUIs. > > Pierre Barbier de Reuille > > Le mar 04/05/2004 ? 16:47, James Gunn a ?crit : > > *** Before acting on this e-mail or opening any attachment you are > > advised to read the disclaimer at the end of this e-mail *** > > > > Hi all, > > > > I've read a few of the previous posts with regard to > redirecting the > > output of PyErr_Print but I've still not managed to do it yet. My > > problem is that I have a GUI-based app that makes calls to > an embedded > > Python interpreter and I need to capture the output of > errors...more > > specifically, I really really need to capture the output of > > Py_CompileString. > > > > I've tried to setup a pipe in a similar way to how Pierre > Barbier de > > Reuille described in his post 08/04/2004 (Re:[C++-sig]how to get > > python exception information in c++?) but it gives me problems. It > > seems that nothing gets written to the pipe as calls to > read it cause > > it to block/wait. > > > > Does anyone have any clues? > > > > Thanks in advance. > > > > James Gunn > > Software Developer > > --LongSig > > > > Computer Bureau > > Communisis DM > > Manston Lane > > Crossgates > > Leeds > > LS15 8AH > > > > Telephone +44 (0)113 225 5306 > > Fax +44 (0)113 225 5921 > > Email James.Gunn at communisis-dm.co.uk > > > > > > > ********************************************************************** > > Please note: This e-mail and its attachments contain only > the opinions > > of the sender and do not necessarily reflect the policy(s) of the > > communisis group in general. > > > > Employees of the communisis group are required not to make any > > defamatory statements and not to infringe or authorise any > > infringement of copyright or any other legal right by > e-mail. Any such > > communication is therefore outside the scope of employment of the > > individual concerned. The communisis group will not accept any > > liability in respect of such a communication. > > > > Confidentiality: This e-mail and any attachments, together > with their > > contents, are confidential unless otherwise explicitly stated in > > writing by the sender of this e-mail and are for the intended > > recipient only. If they have come to you in error you must not take > > any action in respect of them, which includes but is not limited to > > reproducing, sending or storing them, other than to notifying the > > sender immediately of the mistake, and deleting the e-mail, any > > attachments and any reproductions made by replying to it. > > > > Viruses: This e-mail and any attachments have been scanned > for viruses > > but we cannot guarantee that they are virus free. The > recipient should > > check this e-mail and any attachments for viruses. The communisis > > group accepts no responsibility for any damage caused by any virus > > transmitted by this e-mail or any of its attachments. In > the event of > > any unauthorised copying or forwarding, the recipient will > be required > > to indemnify the communisis group against any claim for > loss or damage > > caused by any viruses or otherwise. > > > ********************************************************************** > > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email > Security System. > > For more information please visit http://www.messagelabs.com/email > > > ______________________________________________________________________ > > > > > > > ______________________________________________________________________ > > _______________________________________________ > > C++-sig mailing list > > C++-sig at python.org > > http://mail.python.org/mailman/listinfo/c++-sig > -- > Pierre Barbier de Reuille > > INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP > Botanique et Bio-informatique de l'Architecture des Plantes > TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France > > tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68 > -- > Pierre Barbier de Reuille > > INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP > Botanique et Bio-informatique de l'Architecture des Plantes > TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France > > tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68 > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security > System. For more information please visit > http://www.messagelabs.com/email > ______________________________________________________________________ > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From gwl at u.washington.edu Tue May 4 20:59:09 2004 From: gwl at u.washington.edu (Graeme Lufkin) Date: 04 May 2004 11:59:09 -0700 Subject: [C++-sig] Re: bjam rules for building embedded applications In-Reply-To: References: Message-ID: <1083697149.30940.41.camel@montague.astro.washington.edu> Okay, I've made some additions to the Boost.Python Jamfile that add some templates, and made changes to the tutorial and the building documentation. Attached is the output of 'cvs -Q diff -c' run in my $(BOOST_ROOT). If you need a different format, just let me know how you'd like me to run cvs diff. I use cvs.sourceforge.net, updated this morning. Here is a list of all the files I changed: libs/python/build/Jamfile libs/python/doc/building.html libs/python/doc/tutorial/doc/building_hello_world.html libs/python/doc/tutorial/doc/embedding.html libs/python/example/Jamfile libs/python/example/Jamrules libs/python/example/tutorial/Jamfile tools/build/v1/python.jam In addition to the changed files, I added two files: libs/python/example/tutorial/boost-build.jam libs/python/example/tutorial/Jamrules Since I don't have write access to the repository, you'll need to add these files manually. The Jamrules is identical to libs/python/example/Jamrules, and boost-build.jam is just like libs/python/example/boost-build.jam, just one more '../' in the call to boost-build. Here's a verbal description of what I did, and why. 1.) In tools/build/v1/python.jam, added 'pthread' to list of libraries required to create an embedded Python application. Again, I needed this on my RH9 system, it may not be right for all unices. 2.) In libs/python/build/Jamfile, added templates for embedded apps, and static versions of the extension and embedded templates. I used $(BOOST_PYTHON_V2_PROPERTIES) instead of $(PYTHON_PROPERTIES), contrary to your comment in an earlier post. Since the extension template uses this, I wanted them to be similar. Since the entry for 'lib boost_python' (the static version) also uses it (and hence, the BOOST_PYTHON_DYNAMIC_LIB) successfully, it should do the right thing even for the static templates I wrote. 3.) Added commented-out sample Jamfile entries using the templates mentioned above in libs/python/example/Jamfile. I tested all these examples on my RH9, gcc 3.2.2, Python 2.2.2 system. Also added a comment about ALL_LOCATE_TARGET to libs/python/example/Jamrules 4.) Changed the tutorial to be an "external" project (i.e. to use its own boost-build.jam and Jamrules, hence the added files) that uses the extension template in the Jamfile. 5.) Changed the tutorial documentation of "building hello world" and "building an embedded app" to reflect the new Jamfile syntax using the templates. For the embedded app tutorial page, I changed the last entry of the "4 steps to embedding Python" to tell the user NOT to call Py_Finalize, as postings to the list still talk about problems using this function call. On Sun, 2004-05-02 at 09:01, c++-sig-request at python.org wrote: > > The tutorial says that embedded apps need to use the static versions of > > both libpython and libboost_python. Is this no longer the case (or > > never was the case)? > > Never was. Confirmed, I have no problems doing embedded apps dynamically linked to boost_python. Wrote a template just like the extension one to make it easier to write Jamfile entries for embedded apps. > > Additionally, the Jamfile in $(BOOST_ROOT) has an install > > target that will place the headers and built libraries right where I > > want them. And because several versions (debug/threading/etc) get > > built, I should still be able to make design choices in each individual > > project's Jamfile (that is, use no-debug multithreading here, debug > > singlethreading over here). > > So ideally, I'd like to provide two templates (for both extensions and > > embeds) to use in Jam targets: the current one that builds a separate > > version of libboost_python for each project, > > Well, it doesn't, but... > > > and a new one that links > > against an external version of libboost_python, the location perhaps > > controlled by a variable local to the projects' Jamfile. (And just in > > case it's not clear: I don't currently know how to write such a > > template, help would be appreciated) > > I guess it mostly comes down to using library_name and > path/to/search/for/libs. Right, and I've figured this out now (I hope!). I added some example entries to libs/python/example/Jamfile showing how to link against an external copy of libboost_python using the / business. This works great for dynamic linking, but I can't figure out how do static. More specifically, I want the executable (or Python extension) to link statically against libboost_python.a (not .so!), but still be dynamic against things like libc, libstdc++, etc. I can specify 'static', but this makes everything static, which is not what I want. I looked through the Boost.Build docs, and for v2 found some text talking about specifying static linking on a per-library basis, but couldn't find anything for v1. When I use the static template I wrote, it works fine because Jam sees libboost_python.a as a dependency, and includes it in the link call, instead of a '-lboost_python'. Any thoughts about statically linking against an external version of boost_python? > > Something new: I tried setting ALL_LOCATE_TARGET to a valid directory > > path in the Jamrules file, but it didn't do anything. The example > > Jamrules file has it commented out, has it ever been tried? > > I certainly use that feature all the time, although I set it in my > environment. There were a few weeks when it was broken, but AFAIK > Rene fixed it again before 1.31.0. Oops. Once again, the problem can be traced back to me being an idiot. It's the most common source of problems, I find. ALL_LOCATE_TARGET works as expected. > > I find extracting the library/executable from the deep tree of > > directories that bjam creates to be quite annoying, so would love to > > take advantage of this feature (assuming I'm correctly understanding > > its purpose!). > > Well, maybe you're not. It doesn't make the tree any less deep; it > just unwinds the tree from the build tree (the one containing the > Jamfiles). Okay, I see how this works now. Extracting stuff from the build tree is still annoying, but so are a lot of things in life. -- - Graeme Lufkin gwl at u.washington.edu "This sentence contains exactly threee erors." -------------- next part -------------- ? bin ? mychanges.diff ? libs/python/example/bin ? libs/python/example/tutorial/Jamrules ? libs/python/example/tutorial/boost-build.jam ? tools/build/jam_src/bin.linuxx86 ? tools/build/jam_src/bootstrap.gcc Index: libs/python/build/Jamfile =================================================================== RCS file: /cvsroot/boost/boost/libs/python/build/Jamfile,v retrieving revision 1.34 diff -c -r1.34 Jamfile *** libs/python/build/Jamfile 7 Feb 2004 21:38:24 -0000 1.34 --- libs/python/build/Jamfile 4 May 2004 17:42:58 -0000 *************** *** 69,74 **** --- 69,91 ---- : ../../.. ; + template extension-static + : boost_python + : @boost + ; + + template embedded + : boost_python + : $(BOOST_PYTHON_V2_PROPERTIES) + $(PYTHON_EMBEDDED_LIBRARY) + ; + + template embedded-static + : boost_python + : $(BOOST_PYTHON_V2_PROPERTIES) + $(PYTHON_EMBEDDED_LIBRARY) + ; + lib boost_python : # sources ../src/$(sources) Index: libs/python/doc/building.html =================================================================== RCS file: /cvsroot/boost/boost/libs/python/doc/building.html,v retrieving revision 1.24 diff -c -r1.24 building.html *** libs/python/doc/building.html 13 Apr 2004 12:14:10 -0000 1.24 --- libs/python/doc/building.html 4 May 2004 17:42:59 -0000 *************** *** 288,294 **** set up to automatically rebuild the Boost.Python library in place whenever it's out-of-date rather than just reusing an existing library, so you'll also need the Boost.Python library sources in ! boost/python/src/.

--- 288,296 ---- set up to automatically rebuild the Boost.Python library in place whenever it's out-of-date rather than just reusing an existing library, so you'll also need the Boost.Python library sources in ! boost/python/src/. The example Jamfile contains, commented out, ! several alternate ways of building an extension that you may find useful.

*************** *** 305,312 ****

The libs/python/example subdirectory of your boost installation contains a small example which ! builds and tests two extensions. To build your own extensions copy the ! example subproject and make the following two edits:

  1. --- 307,318 ----

    The libs/python/example subdirectory of your boost installation contains a small example which ! builds and tests two extensions. To build your own extension, create a ! directory for it and copy the files boost-build.jam, Jamrules, ! and Jamfile to it. Note that your project can (and probably should!) ! be located outside of the Boost.Python source tree. ! In your project directory, make the following edits so that Boost.Build can ! find its configuration directories:

    1. Index: libs/python/doc/tutorial/doc/building_hello_world.html =================================================================== RCS file: /cvsroot/boost/boost/libs/python/doc/tutorial/doc/building_hello_world.html,v retrieving revision 1.9 diff -c -r1.9 building_hello_world.html *** libs/python/doc/tutorial/doc/building_hello_world.html 7 Apr 2004 02:25:52 -0000 1.9 --- libs/python/doc/tutorial/doc/building_hello_world.html 4 May 2004 17:42:59 -0000 *************** *** 47,53 ****

      We shall skip over the details. Our objective will be to simply create the ! hello world module and run it in Python. For a complete reference to building Boost.Python, check out: building.html. After this brief bjam tutorial, we should have built two DLLs:

      --- 47,53 ----

      We shall skip over the details. Our objective will be to simply create the ! hello world module and run it in Python. For a more complete reference to building Boost.Python, check out: building.html. After this brief bjam tutorial, we should have built two DLLs:

      *************** *** 58,119 ****

      The tutorial example can be found in the directory: libs/python/example/tutorial. There, you can find:

      !
      • hello.cpp
      • Jamfile

      ! The hello.cpp file is our C++ hello world example. The Jamfile is a ! minimalist bjam script that builds the DLLs for us.

      Before anything else, you should have the bjam executable in your boost directory or somewhere in your path such that bjam can be executed in the command line. Pre-built Boost.Jam executables are available for most ! platforms. For example, a pre-built Microsoft Windows bjam executable can ! be downloaded ! here. ! The complete list of bjam pre-built ! executables can be found ! here.

      Let's Jam!

      ! Here is our minimalist Jamfile:

      !     subproject libs/python/example/tutorial ;
! 
!     SEARCH on python.jam = $(BOOST_BUILD_PATH) ;
!     include python.jam ;
! 
!     extension hello                     # Declare a Python extension called hello
!     :   hello.cpp                       # source
!         <dll>../../build/boost_python   # dependencies
!         ;
!

      ! First, we need to specify our location in the boost project hierarchy. ! It so happens that the tutorial example is located in /libs/python/example/tutorial. ! Thus:

      ! 
      !     subproject libs/python/example/tutorial ;

      ! Then we will include the definitions needed by Python modules:

      ! 
      !     SEARCH on python.jam = $(BOOST_BUILD_PATH) ;
!     include python.jam ;
!

      ! Finally we declare our hello extension:

      ! 
      !     extension hello                     # Declare a Python extension called hello
!     :   hello.cpp                       # source
!         <dll>../../build/boost_python   # dependencies
!         ;
!

      Running bjam

      ! bjam is run using your operating system's command line interpreter.

      !

      Start it up.

      ! Make sure that the environment is set so that we can invoke the C++ ! compiler. With MSVC, that would mean running the Vcvars32.bat batch file. For instance:

            C:\Program Files\Microsoft Visual Studio\VC98\bin\Vcvars32.bat

      ! Some environment variables will have to be setup for proper building of our Python modules. Example:

            set PYTHON_ROOT=c:/dev/tools/python
--- 58,105 ----
  
      
  The tutorial example can be found in the directory:
  libs/python/example/tutorial. There, you can find:
      
! 
        
! 
      • hello.cpp
        • 
! 
      • Jamfile
        • 
! 
      • Jamrules
        • 
! 
      • boost-build.jam
        • 
! 
      
! The file hello.cpp is our C++ hello world example. The Jamfile is a
! minimalist bjam script that builds the DLLs for us.
! The files Jamrules and boost-build.jam tell the build system where to find import configuration info.
      
  
      
  Before anything else, you should have the bjam executable in your boost
  directory or somewhere in your path such that bjam can be executed in
  the command line. Pre-built Boost.Jam executables are available for most
! platforms. 
! Information about downloading/installing Boost.Jam can be found here.
! 
      
  
      Let's Jam!
      
  
      
  
      
! Here is our minimalist Jamfile, with explanatory comments:
      
  
      !     # Specify that this is an independent project
!     project-root ; 
!     # Bring in definitions needed for Python modules
!     import python ;
!     extension hello # Declare a Python extension called hello
!         :   hello.cpp # source
!         #dependencies/flags to make a Python extension using a Boost.Jam template dependency
!         <template>@boost/libs/python/build/extension 
!     ;
  
      
! 
! 
      Running bjam
      
! bjam is run using your operating system's command line interpreter, so start up an instance of the command line.
      
! 
      Make sure that the environment is set so that we can invoke the C++
! compiler. On Unix, you shouldn't have to do anything special. On Windows with MSVC, that would mean running the Vcvars32.bat batch
  file. For instance:
      
  
            C:\Program Files\Microsoft Visual Studio\VC98\bin\Vcvars32.bat
  
      
  
      
! On Windows, some environment variables will have to be set up for proper building of our
  Python modules. Example:
      
  
            set PYTHON_ROOT=c:/dev/tools/python
***************
*** 125,177 ****
  appropriately.  Be sure not to include a third number, e.g. not  "2.2.1",
  even if that's the version you have.
      
  
      
! Now we are ready... Be sure to cd to libs/python/example/tutorial
! where the tutorial "hello.cpp" and the "Jamfile" is situated.
      
! 
      
! Finally:
      
  
      !     bjam -sTOOLS=msvc
! 
      
  
      
! We are again assuming that we are using Microsoft Visual C++ version 6. If
! not, then you will have to specify the appropriate tool. See
! 
! Building Boost Libraries for
! further details.
      
! 
      
! It should be building now:
      
! 
      !     cd C:\dev\boost\libs\python\example\tutorial
!     bjam -sTOOLS=msvc
!     ...patience...
!     ...found 1703 targets...
!     ...updating 40 targets...
! 
      
! And so on... Finally:
      
! 
      !     vc-C++ ..\..\..\..\libs\python\example\tutorial\bin\hello.pyd\msvc\debug\
!     runtime-link-dynamic\hello.obj
!     hello.cpp
!     vc-Link ..\..\..\..\libs\python\example\tutorial\bin\hello.pyd\msvc\debug\
!     runtime-link-dynamic\hello.pyd ..\..\..\..\libs\python\example\tutorial\bin\
!     hello.pyd\msvc\debug\runtime-link-dynamic\hello.lib
!        Creating library ..\..\..\..\libs\python\example\tutorial\bin\hello.pyd\
!        msvc\debug\runtime-link-dynamic\hello.lib and object ..\..\..\..\libs\python\
!        example\tutorial\bin\hello.pyd\msvc\debug\runtime-link-dynamic\hello.exp
!     ...updated 40 targets...
  
      
! If all is well, you should now have:
      
  
      • boost_python.dll
      • hello.pyd
      
  if you are on Windows, and
      
  
      • libboost_python.so
      • hello.so
      
! if you are on Unix.
      
  
      
! boost_python.dll can be found somewhere in libs\python\build\bin
  while hello.pyd can be found somewhere in
! libs\python\example\tutorial\bin. After a successful build, you can just
! link in these DLLs with the Python interpreter. In Windows for example, you
! can simply put these libraries inside the directory where the Python
! executable is.
      
  
      
  You may now fire up Python and run our hello module:
      
  
      --- 111,162 ----
  appropriately.  Be sure not to include a third number, e.g. not  "2.2.1",
  even if that's the version you have.
      
  
      
! Now we are ready, cd to libs/python/example/tutorial
!  and invoke the build system:
      
  
      !     bjam
      
  
      
! This will build a debug version of the Boost.Python library and your extension using the default compiler toolset.
! See Getting Started: Configuring the tools for more details about toolsets.
      
! 
      
! Building will produce plenty of output (sample output is from a Unix system):
      
! 
      ! ...patience...
! ...found 1976 targets...
! ...updating 41 targets...
! MkDir1 bin
! MkDir1 bin/boost
! MkDir1 bin/boost/libs
! MkDir1 bin/boost/libs/python
! MkDir1 bin/boost/libs/python/build
! MkDir1 bin/boost/libs/python/build/libboost_python.so
! MkDir1 bin/boost/libs/python/build/libboost_python.so/gcc
! MkDir1 bin/boost/libs/python/build/libboost_python.so/gcc/debug
! MkDir1 bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true
! gcc-C++-action bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable-true/numeric.o
!  ...
! <snip>
!  ...
! gcc-C++-action bin/tutorial/hello.so/gcc/debug/shared-linkable-true/hello.o
! gcc-Link-action bin/tutorial/hello.so/gcc/debug/shared-linkable-true/hello.so
! Chmod1 bin/tutorial/hello.so/gcc/debug/shared-linkable-true/hello.so
! ...updated 41 targets...
  
      
! If all goes well, there should be a directory tree called bin that contains, deep within:
      
  
      • boost_python.dll
      • hello.pyd
      
  if you are on Windows, and
      
  
      • libboost_python.so
      • hello.so
      
! if you are on Unix.
! Note that, on Unix, the files mentioned above will actually be symlinks to the real libraries, whose filenames will contain the number of the Boost release you're using.
! When we talk about copying the files below, we mean copying both the symlink and the target file.
! 
      
  
      
! boost_python.dll can be found somewhere in bin\boost\libs\python\build
  while hello.pyd can be found somewhere in
! bin\tutorial. 
! To use these libraries, they must be accessible to the Python interpreter.
! In Windows for example, you can copy them to the directory where the Python executable is.
! On Unix, you could copy them to a directory in your $LD_LIBRARY_PATH.
      
  
      
  You may now fire up Python and run our hello module:
      
  
      ***************
*** 179,185 ****
      >>> print hello.greet()
      hello, world
  
      
! 
      There you go... Have fun!
      
--- 164,173 ----
      >>> print hello.greet()
      hello, world
  
! 
      After reading more of the tutorial, you will want to create your own project.
! More information about and examples of Jamfiles and Boost.Python can be found here.
! 
      
! 
      
    
      
      
      
      
Index: libs/python/doc/tutorial/doc/embedding.html
===================================================================
RCS file: /cvsroot/boost/boost/libs/python/doc/tutorial/doc/embedding.html,v
retrieving revision 1.5
diff -c -r1.5 embedding.html
*** libs/python/doc/tutorial/doc/embedding.html	7 Apr 2004 02:25:52 -0000	1.5
--- libs/python/doc/tutorial/doc/embedding.html	4 May 2004 17:42:59 -0000
***************
*** 38,84 ****
  in a future version, it may become unnecessary to touch the Python/C API at
  all. So stay tuned... 
      Building embedded programs
      
! To be able to use embedding in your programs, they have to be linked to
! both Boost.Python's and Python's static link library.
      
! Boost.Python's static link library comes in two variants. Both are located
! in Boost's /libs/python/build/bin-stage subdirectory. On Windows, the
! variants are called boost_python.lib (for release builds) and
! boost_python_debug.lib (for debugging). If you can't find the libraries,
! you probably haven't built Boost.Python yet. See 
! and Testing on how to do this.
      
! 
      
! Python's static link library can be found in the /libs subdirectory of
! your Python directory. On Windows it is called pythonXY.lib where X.Y is
! your major Python version number.
      
! 
      
! Additionally, Python's /include subdirectory has to be added to your
! include path.
      
! In a Jamfile, all the above boils down to:
      !     projectroot c:\projects\embedded_program ; # location of the program
! 
!     # bring in the rules for python
!     SEARCH on python.jam = $(BOOST_BUILD_PATH) ;
!     include python.jam ;
! 
!     exe embedded_program # name of the executable
!       : #sources
!          embedded_program.cpp
!       : # requirements
!          <find-library>boost_python <library-path>c:\boost\libs\python
!       $(PYTHON_PROPERTIES)
!         <library-path>$(PYTHON_LIB_PATH)
!         <find-library>$(PYTHON_EMBEDDED_LIBRARY) ;
! 
      Getting started
      
  Being able to build is nice, but there is nothing to build yet. Embedding
  the Python interpreter into one of your C++ programs requires these 4
  steps:
      
! 
      1. #include <boost/python.hpp>

      2. Call 
! Py_Initialize() to start the interpreter and create the __main__ module.

      3. Call other Python C API routines to use the interpreter.

      4. Call 
! Py_Finalize() to stop the interpreter and release its resources.
      
  (Of course, there can be other C++ code between all of these steps.)
      Now that we can embed the interpreter in our programs, lets see how to put it to use...
      
    
      
      
      
  
  
  
  
  
      
--- 38,86 ----
  in a future version, it may become unnecessary to touch the Python/C API at
  all. So stay tuned... 
      Building embedded programs
      
! Building an application that embeds a Python interpreter using Boost.Python is very similar to building an extension.
! Instead of building a shared library that Python will load, we are building an executable that links against the Python and Boost.Python libraries.
! Also, the Python header files must be accessible so that you can use the Python/C API.
! There is a Jamfile template provided to add these dependencies to your Jamfile entry.
! 
      
! Here's an example Jamfile that builds an embedding application.
! 
      !     project-root ;
!     import python ;
!     exe embedded_program
!         : embedded_program.cpp
!         <template>@boost/libs/python/build/embedded
!         ;
! 
      
! To see what the embedding template does, here is its definition, found in libs/python/build/Jamfile:
! 
      !     template embedded
!         : <dll>boost_python #link against boost_python dynamically
!         : $(BOOST_PYTHON_V2_PROPERTIES) #defined elsewhere, this variable ...
!             # ... adds Python header location to include search path
!             # ... adds Python library location to library search path
!             # ... adds Boost header location to include search path
!         <find-library>$(PYTHON_EMBEDDED_LIBRARY) #link against Python
!         ;
! 
      
! 	
! 
      Getting started
      
  Being able to build is nice, but there is nothing to build yet. Embedding
  the Python interpreter into one of your C++ programs requires these 4
  steps:
      
! 
        
! 
      1. #include <boost/python.hpp>
        2. 
! 
      2. Call Py_Initialize() to start the interpreter and create the __main__ module.
        3. 
! 
      3. Call other Python C API routines to use the interpreter.
        4. 
! 
      4. Don't call Py_Finalize() to stop the interpreter and release its resources.
! Sorry about this one, but calling Py_Finalize() is not yet safe with Boost.Python.
! Expect a fix Real Soon Now.
! 
        5. 
! 
      
! 
      
  (Of course, there can be other C++ code between all of these steps.)
      Now that we can embed the interpreter in our programs, lets see how to put it to use...
      
    
      
  
  
  
  
  
      
Index: libs/python/example/Jamfile
===================================================================
RCS file: /cvsroot/boost/boost/libs/python/example/Jamfile,v
retrieving revision 1.6
diff -c -r1.6 Jamfile
*** libs/python/example/Jamfile	10 Sep 2003 16:08:41 -0000	1.6
--- libs/python/example/Jamfile	4 May 2004 17:42:59 -0000
***************
*** 42,49 ****
      # extension modules to use
      getting_started1 ;
      
- 
-     
  # ----- getting_started2 -------
      
  # Declare a Python extension called getting_started2
--- 42,47 ----
***************
*** 60,63 ****
      :  # Python test driver
      test_getting_started2.py
      # extension modules to use
!     getting_started2 ;    
\ No newline at end of file
--- 58,108 ----
      :  # Python test driver
      test_getting_started2.py
      # extension modules to use
!     getting_started2 ;
! 
! # ----- More Examples -------
! #  Examples of alternate ways to build Boost.Python extensions and applications
! # To see what the templates do, look at their definition in libs/python/build/Jamfile
! 
! #  By default, extensions link against the shared version of boost_python
! # You can use the extension-static template to link against the static version,
! # in which case you only need to copy/distribute your shared library.
! #extension getting_started1-static
! #	: getting_started1.cpp
! #