|
Boost-Build : |
From: Roberto Aguilar (roberto.c.aguilar_at_[hidden])
Date: 2006-07-28 22:31:33
Hello,
I just started working with Boost and became interested in using the
Boost.Build system for all the source code I'm maintaining. The code
is a mix of C, C++, Python, Perl and Fortran. I decided to start
working with Boost.Build v2 and tried to see if I can build a python
program. I created a tree structure like so:
top/
|
+-- Jamroot
|
+-- apps/
| |
| +-- pytest/
| | -- Jamfile
| | -- pytest (this is a python script)
|
+-- libs/
| |
| +-- pylib/
| | | -- Jamfile
| | | -- pylib.py
| |
| +-- cpplib/
| | | -- Jamfile
| | | -- cpplib.cpp (this is a Boost.Python "wrapper")
First, I checked ${BOOST_ROOT}/tools/build/v2/tools and saw that there
is a python.jam file, but it looks like it is strictly for building
Python C++ extensions. So, I read the documentation on how to build
my own generator.
I have run into some snags here. The following is the contents of my
attempt at a generator, which I called pytools.jam:
---- import type ; type.register PYTOOLS : py ; type.register PYCOMPILED : pyc ; import generators ; generators.register-standard pytools.pycmd : PYTOOLS : ?? ; actions pycmd { # does it make sense to "use clone-and-change-target-type" here? } generators.register-standard pytools.pylib : PYTOOLS : PYCOMPILED ; actions pylib { "python /sw/lib/python2.4/py_compile.py" $(>) $(<) } ---- For a python command, when it's installed I don't want it to have the .py extension, so I am not exactly sure how to finish off the "generators.register-standard" line. Also, looking through ${BOOST_ROOT}/tools/build/v2/build/generators.jam I found the clone-and-change-target-type rule. This sounds like it will take my .py file and change it to a type that strips off the extension when installing it. Would this be the right approach? For a pure python library, I'd want the .py files to be byte-compiled when being installed. So, pretty much taking the example from the documentation in, "Chapter 5. Extender Manual", I came up with the pylib action. Here, I just need to figure out how to make the location of py_compile.py generic. The reason I want to have a target for python commands is so that Boost.Build does the dependency tracking of python libraries for me. So, for instance if pycmd depends on both pylib and cpplib, Boost.Build takes care of making sure the deps are up to date. I believe I'm approaching this the right way; any help is greatly appreciated! Thanks! -Roberto.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk