Re: [C++-sig] Linking issues with Boost.Python
On 17 Aug 2010 at 14:20, David Aldrich wrote: > I would be grateful for some help with setting up some makefiles for my > C++ application, compiled with gcc under Linux, that uses Boost.Python. I would strongly recommend that you use something more modern than GNU make. Boost's build system is much better. The one I use is scons (http://www.scons.org/) whose only main fault is O(N^2) scaling to source file number, a problem they are in the process of fixing. Scons has the *major* advantage of its build config being python source. So its SConstruct and SConscript files are literally straight python. > Now I want to move Py_Initialize() to my main() function, and invoke the > Python interpreter from the shared library as before. So I linked the > application to the Python and Boost libraries in my top level makefile, > and deleted mention of the Python and Boost libraries from the shared > library's makefile. The result all links without errors but the Python > calls do nothing. Each thing which uses python ought to separately link to python and Boost.Python if necessary. You then leave the runtime linker figure it all out. If you were using scons or make, have a separate build config per DLL i.e. each DLL/shared object is a separate project. If you're using dlopen() to load these libraries at runtime make SURE you use RTLD_GLOBAL, otherwise you'll get multiple copies of BPL and python and it won't work. > If I use Boost.Python in a shared library, do I have to link > Boost.Python to it when I build it, or would linking Boost.Python to the > main application be sufficient? I think the command on Linux for checking what libraries link to what is 'ldd'. Use on each shared library to ensure its individual dependencies are satisfied. HTH, Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Linking issues with Boost.Python
Hi Niall > I would strongly recommend that you use something more modern than > GNU make. Boost's build system is much better. The one I use is scons > (http://www.scons.org/) whose only main fault is O(N^2) scaling to > source file number, a problem they are in the process of fixing. I take your point. Personally, I find makefiles very hard to maintain. In particular, our #include dependency management is indecipherable! I guess the obvious replacements are SCons and CMake. I will take a look at these. Should one consider bjam? Thanks very much for answering my other questions. Best regards David ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Linking issues with Boost.Python
David Aldrich wrote: I would strongly recommend that you use something more modern than GNU make. Boost's build system is much better. The one I use is scons (http://www.scons.org/) whose only main fault is O(N^2) scaling to source file number, a problem they are in the process of fixing. Should one consider bjam? That's what Niall meant by "Boost's build system." Boost.Build uses bjam as its engine, with substantial work around that. I've always found bjam syntax a bit off-putting, and I've never read the available Boost.Build documentation, which is probably superb. So in fairness to the work of many others, I'll only note that many of the questions on the boost-users mailing list seem to be from people confused by proper use of '--' on the bjam command line, proper placement of spaces and commas in the configuration files, etc. I really want to like scons: I see no need to invent a whole new language for a build engine. That said, our organization presently uses CMake. ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Linking issues with Boost.Python
On 18 Aug 2010 at 15:32, David Aldrich wrote: > > I would strongly recommend that you use something more modern than > > GNU make. Boost's build system is much better. The one I use is scons > > (http://www.scons.org/) whose only main fault is O(N^2) scaling to > > source file number, a problem they are in the process of fixing. > > I take your point. Personally, I find makefiles very hard to maintain. > In particular, our #include dependency management is indecipherable! I > guess the obvious replacements are SCons and CMake. I will take a look > at these. Yeah scons is particularly outstanding with handling dependencies, though it's exactly that which is introducing the O(N^2) complexity. It goes off and works out what they are for you as a default and then you can programatically override if you need to. Unlike other build systems, you really can program the build system down to a fine detail. Want some crazy build and dependency system which calls a series of munge scripts to auto-generate C++ and/or GLSL shader programs in a recursive descent? Want to build eight different versions of the same DLL each with slightly different configuration and slightly different name, and then get parent projects to choose the right binary to link against according to a set of heuristics? Want to have the build system fire up a copy of VirtualBox running some arbitrary operating system, compile some sources there checked out from the local GIT repo and push them into the local build? None of these are a problem with scons, mainly because scons IS python and anything python can do your build can do. > Should one consider bjam? As Nat said, bjam is the core of Boost Build but Boost adds a lot to it. I've always found it lacking in configurability personally, and like Nat I'm also not fond of its syntax either - much like CMake too. I will say though that bjam scales very well and has no issue with truly huge projects. But as you might guess from my examples above, I program my build environment much as I program applications. Anything which saves time in the long run really, and for me almost all build systems which are 100% OS portable don't cut it here. If it weren't for the O(N^2) scaling problem, I'd actually say it's the perfect build system unless you hate python. And certainly given we're in the C++ SIG for python it's hard not to naturally recommend it! HTH, Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
