Merge lp:~nschloe/libadjoint/cmake into lp:libadjoint

[Nico Schlömer]

Added CMake interface.

[Patrick Farrell (pefarrell)]

Hi Nico!

Thanks for starting this work. libadjoint badly needs it, a proper installation procedure is a high priority.

This is a good start, but it's not quite there.

(a) Could you please change the INSTALL to give instructions on how to build using cmake? (Let's remove the old Makefile completely once this works, it is a mess.) Make sure to mention how to tell cmake to install it in a particular directory.

(b) There is a C header, include/libadjoint/adj_constants.h, that is also necessary to use from Fortran. At present, a simple sed script converts adj_constants.h into adj_constants_f.h, which cmake currently neglects, causing a clean build to fail:

[farrellp@blossom:~/src/libadjoint/build]$ make
Scanning dependencies of target adjoint
[ 5%] Building Fortran object src/CMakeFiles/adjoint.dir/adj_fortran.F90.o
/home/farrellp/src/libadjoint/include/libadjoint/adj_fortran.h:1:0: fatal error: libadjoint/adj_constants_f.h: No such file or directory
compilation terminated.
make[2]: *** [src/CMakeFiles/adjoint.dir/adj_fortran.F90.o] Error 1
make[1]: *** [src/CMakeFiles/adjoint.dir/all] Error 2
make: *** [all] Error 2

Now, the easiest thing to do is to change the .h so that it can be used directly from both C and Fortran. This involves getting rid of all the comments, and renaming adj_scalar_f to adj_f_scalar everywhere.

I'm sure there will be more issues once we overcome this!

Cheerio,

Patrick

[lp:~nschloe/libadjoint/cmake]

434. By Nico Schlömer on 2013-10-08

added build instructions for CMake

435. By Nico Schlömer on 2013-10-08

add Fortran header file hack

[Nico Schlömer (nschloe)]

Even easier: I added the same Fortran header hack to CMake. The hack can be removed at a later time.

[Patrick Farrell (pefarrell)]

Hey Nico,

Great.

(a) Can you make it build the shared library by default?

(b) The Python bindings need a little bit more work:
  (i) clibadjoint.py (Makefile:315) needs to be generated. The Python bindings depend on this. It's generated using gccxml.
  (ii) clibadjoint_constants.py (Makefile:327) also needs to be generated.
  (iii) clibadjoint.py needs to have the location of libadjoint.so hardcoded in it, which is currently the purpose of Makefile:344.

I think it's close. Hopefully with those changes the Python bindings will work and then this will be mergeable.

[Nico Schlömer (nschloe)]

I'll just try and literally translate the commands over to CMake. There are so many dark hacks in there though that this part of the configuration should be revised after this.

[Patrick Farrell (pefarrell)]

I see where you're coming from. We started off without any dark hacks, but unfortunately they turned out to be necessary for different situations (especially OSX, which is a royal pain). For the Python bindings, I'd like

(i) that the ctypes wrapper is generated automatically from the header (currently done with gccxml), and
(ii) ideally, that it is in pure Python (so we don't have an extra external compiled dependency).

Anyway, just translate the dark hacks over and I'll look into changing it when it works.

[lp:~nschloe/libadjoint/cmake]

436. By Nico Schlömer on 2013-10-08

always build shared library

437. By Nico Schlömer on 2013-10-08

start working on the python bindings

[Nico Schlömer (nschloe)]

I just worked some more on the Python binding mess in CMake and I must say that I don't think I get it done. It just takes *so* much time trying to figure out what all those scripts are doing, and I'm having a hard time pointing out debugging since I don't know what the various created files are supposed to look like. Any support appreciated.

[Nico Schlömer (nschloe)]

> (ii) ideally, that it is in pure Python (so we don't have an extra external
> compiled dependency).

I'd say ideally, the configuration utility, i.e. CMake, takes care of the configuration. All those Python helper scripts should be made redundant.

[Patrick Farrell (pefarrell)]

I agree it's not obvious, but it's not that bad.

The only complex one is the generation of clibadjoint.py Basically, if you were typing it from the command line, it would look like

cpp -DPYTHON_BINDINGS include/libadjoint/libadjoint.h > include/libadjoint/pylibadjoint.h
sed -i "s/__builtin___stpncpy_chk/__builtin___strncpy_chk/" include/libadjoint/pylibadjoint.h # this is a bug in OSX
python/ctypeslib/scripts/h2xml.py -q -I. include/libadjoint/pylibadjoint.h -o python/libadjoint/libadjoint.xml
rm -f include/libadjoint/pylibadjoint.h
python/ctypeslib/scripts/xml2py.py -r '^adj.*' -l /home/pef/src/libadjoint/lib/libadjoint.so python/libadjoint/libadjoint.xml -o python/libadjoint/clibadjoint.py

Does that help?

I took a quick look at using ctypesgen to generate the ctypes API, but the resulting clibadjoint.py segfaults for some reason I don't yet understand.

[lp:~nschloe/libadjoint/cmake]

438. By Nico Schlömer on 2013-10-09

fixes to the cmake/python magic

439. By Nico Schlömer on 2013-10-09

work on after-installation script

440. By Nico Schlömer on 2013-10-09

don't mess around with clibadjoint.py after installation

[Nico Schlömer (nschloe)]

> cpp -DPYTHON_BINDINGS include/libadjoint/libadjoint.h > include/libadjoint/pylibadjoint.h

It turns out one cannot use the CXX compiler here, but the *C* compiler. The variable name CPP in Makefile is really misleading. Also, the "-E" option was missing.

I fiddled around some more and I think we might be with CMake where we are with Makefile. Check it out.

That said, there *has* to be a simpler way of generating the Python bindings than the magic dance we're doing right now. Unfortunately I'm not too experienced in this though.

[lp:~nschloe/libadjoint/cmake]

441. By Nico Schlömer on 2013-10-09

remove redundant comments

[Patrick Farrell (pefarrell)]

CPP always means the C preprocessor. That's why CXX is the variable name for C++ (usually).

On a clean checkout:

bzr co lp:libadjoint
bzr merge lp:~nschloe/libadjoint/cmake
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/tmp/libadjoint/cmake-install -DBUILD_SHARED_LIBS:BOOL=TRUE

yields an error

-- Found PythonInterp: /usr/bin/python (found version "2.7.3")
Traceback (most recent call last):
  File "/home/pef/src/libadjoint/python/ctypeslib/scripts/xml2py.py", line 10, in <module>
    sys.exit(main())
  File "/usr/lib/pymodules/python2.7/ctypeslib/xml2py.py", line 166, in main
    dlls = [load_library(name) for name in options.dlls]
  File "/usr/lib/pymodules/python2.7/ctypeslib/xml2py.py", line 162, in load_library
    return CDLL(path, mode=mode)
  File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: /home/pef/src/libadjoint/lib/libadjoint.so: cannot open shared object file: No such file or directory
/home/pef/src/libadjoint/

It looks like it's trying to generate the Python bindings before the library is actually built.

Aside: At the moment, it's rigged up to automatically generate the Python bindings each time the library is compiled. But libadjoint is pretty stable, and its API isn't going to change dramatically; and as you point out, the Python binding generation is complicated and confusing for other contributors. I'd be happy instead to just freeze the automatically generated Python bindings --- to add clibadjoint.py and clibadjoint_constants.py to the repository, and pull out all of the Python binding generation stuff to a separate script that's invoked manually. What do you think? It would make your life a lot easier.

[lp:~nschloe/libadjoint/cmake]

442. By Nico Schlömer on 2013-10-11

make sure that custom code is executed *after* libadjoint.so is built

[Nico Schlömer (nschloe)]

> CPP always means the C preprocessor.

Right! Too often I mix it up with CXX as in "cee plus plus".

I could reproduce the error that you're getting and I think I fixed most of it. The only thing that's not quite consistent yet is the installation of the generated files, but we're getting there.

> Aside: At the moment, it's rigged up to automatically generate the Python bindings each time the library is compiled.

Instead of freezing the bindings, maybe we should look at what other packages with Python interfaces are doing. For one, I keep seeing SWIG a lot. We can check it out later.

[Patrick Farrell (pefarrell)]

Same attempt at building:

bzr co lp:libadjoint
cd libadjoint
bzr merge lp:~nschloe/libadjoint/cmake
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX:PATH=/tmp/libadjoint/cmake-install -DBUILD_SHARED_LIBS:BOOL=TRUE
make
Removing libadjoint.xml...
Changing permissions on clibadjoint.py...
Adaptations for clibadjoint.py...
/bin/sh: 1: Syntax error: "(" unexpected
make[2]: *** [src/libadjoint.so.0.9.2] Error 2
make[1]: *** [src/CMakeFiles/adjoint.dir/all] Error 2
make: *** [all] Error 2

Any thoughts? Almost there.

[lp:~nschloe/libadjoint/cmake]

443. By Nico Schlömer on 2013-10-14

create clibadjoint_constants.py in the build directory

444. By Nico Schlömer on 2013-10-14

make sure to install the generated python files

[Nico Schlömer (nschloe)]

It should be good to install now.

[Patrick Farrell (pefarrell)]

Hey Nico,

The CMake install looks great, now. I think that's correct.

I'd like to keep the Makefile pathway available for a little while (especially with platforms like OSX, where the OS is broken in countless little ways). You changed tools/create_python_constants.py to take in a source_path and a target_path; can you modify the Makefile, too? Should be just change

@python ./tools/create_python_constants.py

to

@python ./tools/create_python_constants.py $(PWD) $(ABSDESTDIR)

Also: do you know anything about changing the Debian packaging to use CMake (debian/rules)? I think we should make it the default. If you don't know anything about this, I'll try to figure out it later this week.

[Patrick Farrell (pefarrell)]

Update: the Debian packaging *might* be as easy as changing

dh --with=$(PYSUPPORT) $@

to

dh --buildsystem=cmake --with=$(PYSUPPORT) $@

in debian/rules.

[lp:~nschloe/libadjoint/cmake]

445. By Nico Schlömer on 2013-10-14

make sure the Makefile works again

[Nico Schlömer (nschloe)]

> target_path; can you modify the Makefile, too? Should be just change
> @python ./tools/create_python_constants.py
> to
> @python ./tools/create_python_constants.py $(PWD) $(ABSDESTDIR)

Done.

> Also: do you know anything about changing the Debian packaging to use CMake
> (debian/rules)?

Yes. The easiest (and recommended) way for this would be to have

%:
  dh $@ --with python2

in `rules`. This should take care of everything automatically. Also, `cmake` should go in the Build-Depends in `control`. Check out https://wiki.debian.org/Python/TransitionToDHPython2 for more details if needed, or see my Trilinos Debian builds, <https://github.com/nschloe/trilinos-ubuntu/tree/master/debian.raring> (which are similar to libadjoint in that Trilinos contains Fortran and Python extensions as well).

[Patrick Farrell (pefarrell)]

Yes, I already do use dh in debian/rules. The issue is that in dh's list of possible build targets, a simple makefile comes before cmake (see dh_auto_build --list). That's why we need to tell it to use cmake explicitly.

[Nico Schlömer (nschloe)]

Ah I see. Well, you've got it figured out already.
Feel free to merge the branch and move it over to bitbucket/github then. :)

[Patrick Farrell (pefarrell)]

One quick question. Is it possible to get cmake to build both the shared and static versions of the library?

[lp:~nschloe/libadjoint/cmake]

446. By Nico Schlömer on 2013-10-14

build both shared and static libraries by default

[Nico Schlömer (nschloe)]

I added this functionality, but I must say I find it somewhat unclean since this is a decision that the user classically has to make at configure time. All objects need to be rebuilt anyways.

[Patrick Farrell (pefarrell)]

I appreciate where you're coming from. The only reason I ask is that I want to build both the .a and the .so for the Debian packaging. If you can suggest a cleaner way (where there's a command line -DCMAKE_SOME_SWITCH) to turn on building the .a, I'd be all for it.

[Nico Schlömer (nschloe)]

I remember that I once tried to do something similar, but couldn't find a clean solution. I would suggest to build both shared and static the way it is done right now, and revisit this later.

[Patrick Farrell (pefarrell)]

Dear Nico,

Nice work! I think my modifications of your branch at lp:~libadjoint/libadjoint/cmake are in an mergeable state.

I have one last question. Debian packages require
(a) a different layout of Python files (setup.py install --install-layout=deb)
(b) building with each of the versions of Python on the system (loop over pyversions -r)
(c) to install into DESTDIR/prefix (so that it can bundle all the files in DESTDIR)

Currently these things aren't taken care of by the CMake build system. Do you think it is possible? If so, we could set the Debian packaging to build with CMake, and get rid of the Makefile entirely.

If not, I'll merge the branch, although I think it's a bit ugly to have one build system for Debian packaging and one for users installing from source.

[Nico Schlömer (nschloe)]

I'm not sure if I unterstand completely. Is there a repo for the Debian packaging of libadjoint so I can look at it?

> (a) a different layout of Python files (setup.py install --install-layout=deb)

No Debian package should install files outside of the build tree, and libadjoint doesn't either. Everything seems okay to me.

> (b) building with each of the versions of Python on the system (loop over pyversions -r)

Isn't the Debian packager taking care of Python versions?

> (c) to install into DESTDIR/prefix (so that it can bundle all the files in DESTDIR)

You can of course specify the prefix (-DCMAKE_INSTALL_PREFIX:PATH=<path>), but I don't think that one should do that.

> If not, I'll merge the branch.

I'd agree with merging, and dealing with the packaging issues in a second thread (maybe already on GitHub/bitbucket).

[Patrick Farrell (pefarrell)]

All the Debian packaging lives in the main repository, in debian/rules (which sets some variables that are used by Makefile).

(a) I'm not talking about installing files outside the build tree. I'm talking about how they are laid out in the build tree. For example, a python-foo-*.deb will have files in /usr/lib/python2.7/dist-packages/, but setup.py will by default install in site-packages (this is one of the things that python setup.py install --install-layout=deb changes).

(b) Yep. Since I'm the Debian packager, I take care of it, on Makefile:340.

(c) That's different to the prefix. Typically the prefix (./configure --prefix or -DCMAKE_INSTALL_PREFIX) will be /usr, but there's an *additional* variable DESTDIR that gets prepended (e.g. if I'm building in /tmp/foo, DESTDIR will be /tmp/foo/debian/python-foo, and prefix will be /usr, for an install path of /tmp/foo/debian/python-foo/usr/lib/python2.7/dist-packages/foo).

I'll merge anyway.

Thanks for all your help!

Patrick

=== added file 'CMakeLists.txt'
--- CMakeLists.txt	1970-01-01 00:00:00 +0000
+++ CMakeLists.txt	2013-10-14 16:42:35 +0000
@@ -0,0 +1,24 @@
+cmake_minimum_required(VERSION 2.8)
+
+project(libadjoint C CXX Fortran)
+
+# Set the version. (Used for so-naming of the library.)
+set(libadjoint_MAJOR_VERSION 0)
+set(libadjoint_MINOR_VERSION 9)
+set(libadjoint_PATCH_VERSION 2)
+set(libadjoint_VERSION
+    ${libadjoint_MAJOR_VERSION}.${libadjoint_MINOR_VERSION}.${libadjoint_PATCH_VERSION})
+
+# Build shared library.
+SET(BUILD_SHARED_LIBS ON)
+
+# Offer the user the choice of overriding the installation directories
+set(INSTALL_LIB_DIR "lib" CACHE PATH
+    "Installation directory for libraries")
+set(INSTALL_BIN_DIR "bin" CACHE PATH
+    "Installation directory for executables")
+set(INSTALL_INCLUDE_DIR "include/libadjoint" CACHE PATH
+    "Installation directory for header files")
+
+add_subdirectory(src)
+add_subdirectory(python)

=== modified file 'INSTALL'
--- INSTALL	2012-03-23 09:56:49 +0000
+++ INSTALL	2013-10-14 16:42:35 +0000
@@ -4,6 +4,44 @@
 sudo apt-get update
 sudo apt-get install libadjoint libadjoint-dev python-libadjoint
 
+Compiling libadjoint
+====================
+
+If you would like to configure and compile libadjoint yourself, you have two
+possibilities. Using CMake is recommended.
+
+Using CMake
+-----------
+
+Create a separate build directory next to the libadjoint source and run CMake
+in it:
+
+$ ls
+libadjoint-0.9.2
+$ mkdir build
+$ cd build
+$ cmake ../libadjoint-0.9.2
+
+All typical CMake commands are available. For example to set the compiler,
+specify the installation directory, and build a shared library, you would
+execute
+
+$ CC=mpicc CXX=mpicxx FC=mpif90 cmake \
+    -DCMAKE_INSTALL_PREFIX:PATH=/custom/install/path \
+    -DBUILD_SHARED_LIBS:BOOL=TRUE \
+    ../source
+
+After the CMake configuration, type
+
+$ make
+$ make install
+
+in the build directory to build and install libadjoint.
+
+
+Using Makefile
+------------
+
 The minimum requirements for compiling libadjoint are a C compiler 
 (environment variable CC) and a C++ compiler (environment variable
 CXX). If these are not specified, the defaults are 'mpicc' and 'mpicxx'.

=== modified file 'Makefile'
--- Makefile	2013-03-02 14:58:55 +0000
+++ Makefile	2013-10-14 16:42:35 +0000
@@ -326,7 +326,7 @@
 	@chmod a-x python/libadjoint/clibadjoint.py
 python/libadjoint/clibadjoint_constants.py:
 	@echo "  PYTHON tools/create_python_constants.py"
-	@python ./tools/create_python_constants.py
+	@python ./tools/create_python_constants.py $(PWD) $(ABSDESTDIR)
 endif
 
 install: lib/libadjoint.a lib/$(SLIB)

=== added file 'python/CMakeLists.txt'
--- python/CMakeLists.txt	1970-01-01 00:00:00 +0000
+++ python/CMakeLists.txt	2013-10-14 16:42:35 +0000
@@ -0,0 +1,28 @@
+# Python bindings.
+# <http://bloerg.net/2012/11/10/cmake-and-distutils.html>
+find_package(PythonInterp)
+if(PYTHONINTERP_FOUND)
+    set(SETUP_PY_IN "${CMAKE_CURRENT_SOURCE_DIR}/setup.py.in")
+    set(SETUP_PY "${CMAKE_CURRENT_BINARY_DIR}/setup.py")
+    set(DEPS   "${CMAKE_CURRENT_SOURCE_DIR}/libadjoint/__init__.py")
+    set(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/build")
+
+    # Generate setup.py
+    configure_file(${SETUP_PY_IN} ${SETUP_PY})
+
+    # Run `python setup.py -q build`
+    add_custom_command(
+      OUTPUT ${OUTPUT}/timestamp
+      COMMAND ${PYTHON_EXECUTABLE} ${SETUP_PY}
+      ARGS  -q build
+      COMMAND ${CMAKE_COMMAND} -E touch ${OUTPUT}
+      DEPENDS ${DEPS}
+    )
+
+    add_custom_target(target ALL DEPENDS ${OUTPUT}/timestamp)
+
+    # Run `python setup.py install`
+    install(CODE
+            "execute_process(COMMAND ${PYTHON_EXECUTABLE} ${SETUP_PY} -q install --prefix=${CMAKE_INSTALL_PREFIX})"
+           )
+endif()

=== added file 'python/setup.py.in'
--- python/setup.py.in	1970-01-01 00:00:00 +0000
+++ python/setup.py.in	2013-10-14 16:42:35 +0000
@@ -0,0 +1,15 @@
+from distutils.core import setup, Extension
+
+python_utils=Extension("libadjoint.python_utils",
+                       sources=["${CMAKE_CURRENT_SOURCE_DIR}/libadjoint/adj_python_utils.c"]
+                       )
+
+setup (name = 'libadjoint',
+       version = '${libadjoint_VERSION}',
+       description = 'libadjoint python bindings',
+       author = 'The libadjoint team',
+       author_email = '[e-mail]',
+       packages = ['libadjoint'],
+       package_dir={ '': '${CMAKE_CURRENT_SOURCE_DIR}' },
+       #package_dir = {'libadjoint': 'libadjoint'},
+       ext_modules = [python_utils])

=== added file 'src/CMakeLists.txt'
--- src/CMakeLists.txt	1970-01-01 00:00:00 +0000
+++ src/CMakeLists.txt	2013-10-14 16:42:35 +0000
@@ -0,0 +1,118 @@
+include_directories(${libadjoint_SOURCE_DIR}/include)
+
+# Here comes a hack: The C headers are adapted for inclusion in Fortran files.
+# TODO remove this hack
+execute_process(COMMAND sh -c "sed -e 's@/\\*@!@' -e 's@\\*/@@' -e 's@ADJ_CONSTANTS_H@ADJ_CONSTANTS_F_H@' -e '/adj_scalar /d' ${libadjoint_SOURCE_DIR}/include/libadjoint/adj_constants.h > ${libadjoint_SOURCE_DIR}/include/libadjoint/adj_constants_f.h")
+execute_process(COMMAND sh -c "grep '^#' ${libadjoint_SOURCE_DIR}/include/libadjoint/adj_error_handling.h | grep -v '^#include' | grep -v 'CHKMALLOC' > ${libadjoint_SOURCE_DIR}/include/libadjoint/adj_error_handling_f.h")
+
+file(GLOB libadjoint_SRCS
+     "${CMAKE_CURRENT_SOURCE_DIR}/*.c"
+     "${CMAKE_CURRENT_SOURCE_DIR}/*.cpp"
+     "${CMAKE_CURRENT_SOURCE_DIR}/*.F90"
+     )
+file(GLOB libadjoint_HEADERS
+     "${libadjoint_SOURCE_DIR}/include/libadjoint/*.h"
+     "${libadjoint_SOURCE_DIR}/include/libadjoint/*.mod"
+     )
+
+# Build both shared and static libraries here. Do not share the object files
+# (which would be possible using CMake's OBJECT keyword) since objects intended
+# for linking into a shared library need to be compiled with -fPIC.
+add_library(adjoint SHARED ${libadjoint_SRCS})
+
+set_target_properties(adjoint PROPERTIES
+  PUBLIC_HEADER "${libadjoint_HEADERS}"
+  VERSION ${libadjoint_VERSION}
+  SOVERSION ${libadjoint_MAJOR_VERSION}
+  )
+
+add_library(adjoint-static STATIC ${libadjoint_SRCS})
+set_target_properties(adjoint-static PROPERTIES
+  OUTPUT_NAME adjoint
+  )
+
+# Installation of the program
+install(TARGETS adjoint
+  # We don't actually need the RUNTIME DESTINATION here since we're only
+  # installing a library.
+  RUNTIME DESTINATION "${INSTALL_BIN_DIR}" COMPONENT bin
+  LIBRARY DESTINATION "${INSTALL_LIB_DIR}" COMPONENT shlib # .so
+  ARCHIVE DESTINATION "${INSTALL_LIB_DIR}" COMPONENT shlib # .a
+  PUBLIC_HEADER DESTINATION "${INSTALL_INCLUDE_DIR}" COMPONENT dev
+  #PUBLIC_HEADER DESTINATION "${INSTALL_INCLUDE_DIR}/libadjoint" COMPONENT dev
+  )
+
+# -----------------------------------------------------------------------------
+# Now some hardcore hacks for the Python bindings.
+find_package(PythonInterp REQUIRED)
+
+# 1.) Generate pylibadjoint.h and mess around with it.
+add_custom_command(TARGET adjoint
+                   POST_BUILD
+                   COMMAND ${CMAKE_C_COMPILER} -E -U__BLOCKS__ -DPYTHON_BINDINGS ${libadjoint_SOURCE_DIR}/include/libadjoint/libadjoint.h > ${CMAKE_BINARY_DIR}/pylibadjoint.h
+                   COMMENT "Generating pylibadjoint.h..."
+                   )
+                 add_custom_command(TARGET adjoint
+                                    POST_BUILD
+                                    COMMAND sed -i s/__builtin___stpncpy_chk/__builtin___strncpy_chk/ ${CMAKE_BINARY_DIR}/pylibadjoint.h
+                                    COMMENT "Adapting pylibadjoint.h..."
+                                    )
+                 add_custom_command(TARGET adjoint
+                                    POST_BUILD
+                                    COMMAND ${libadjoint_SOURCE_DIR}/python/ctypeslib/scripts/h2xml.py -q -I. ${CMAKE_BINARY_DIR}/pylibadjoint.h -o ${CMAKE_BINARY_DIR}/libadjoint.xml
+                                    COMMENT "Generating libadjoint.xml..."
+                                    )
+                 add_custom_command(TARGET adjoint
+                                    POST_BUILD
+                                    COMMAND rm -f ${CMAKE_BINARY_DIR}/include/libadjoint/pylibadjoint.h
+                                    COMMENT "Removing pylibadjoint.h..."
+                                    )
+                 get_filename_component(LIB_REALPATH ${CMAKE_BINARY_DIR}/src/libadjoint.so
+                                        REALPATH
+                                        )
+                 add_custom_command(TARGET adjoint
+                                    POST_BUILD
+                                    COMMAND ${libadjoint_SOURCE_DIR}/python/ctypeslib/scripts/xml2py.py -r '^adj.*' -l ${LIB_REALPATH} ${CMAKE_BINARY_DIR}/libadjoint.xml -o ${CMAKE_BINARY_DIR}/clibadjoint.py
+                                    COMMENT "Generating clibadjoint.py..."
+                                    )
+                 # Some extra adaptations for OS X.
+                 IF(APPLE)
+                     add_custom_command(TARGET adjoint
+                                        POST_BUILD
+                                        COMMAND sed -i \"s/._pack_ = 4/._pack_ = 8/\" ${CMAKE_BINARY_DIR}/clibadjoint.py
+                                        COMMENT "Adaptations for OS X..."
+                                        )
+                 ENDIF()
+                 add_custom_command(TARGET adjoint
+                                    POST_BUILD
+                                    COMMAND rm -f ${CMAKE_BINDARY_DIR}/libadjoint.xml
+                                    COMMENT "Removing libadjoint.xml..."
+                                    )
+                 add_custom_command(TARGET adjoint
+                                    POST_BUILD
+                                    COMMAND chmod a-x ${CMAKE_BINARY_DIR}/clibadjoint.py
+                                    COMMENT "Changing permissions on clibadjoint.py..."
+                                    )
+
+                 # 2.) Make sure that the installed clibadjoint.py has the
+                 #     location of the shared library hardcoded in it.
+                 add_custom_command(TARGET adjoint
+                                    POST_BUILD
+                                    COMMAND sed -i -e "s@CDLL\\('${libadjoint_SOURCE_DIR}/lib/libadjoint.so'\\)@CDLL\\('${CMAKE_INSTALL_PREFIX}/${INSTALL_LIB_DIR}/libadjoint.so'\\)@" -e "s@CDLL\\('${LIB_REALPATH}'\\)@CDLL\\('${CMAKE_INSTALL_PREFIX}/${INSTALL_LIB_DIR}/libadjoint.so'\\)@" ${CMAKE_BINARY_DIR}/clibadjoint.py
+                                    COMMENT "Adaptations for clibadjoint.py..."
+                                    )
+
+                 # 3.) Generate python/libadjoint/clibadjoint_constants.py via
+                 #     a Python script.
+                 add_custom_command(TARGET adjoint
+                                    POST_BUILD
+                                    COMMAND ${PYTHON_EXECUTABLE} ${libadjoint_SOURCE_DIR}/tools/create_python_constants.py ${libadjoint_SOURCE_DIR} ${CMAKE_BINARY_DIR}
+                                    COMMENT "Generating clibadjoint_constants.py..."
+                                    )
+
+# Make sure to install the generated files
+install(FILES ${CMAKE_BINARY_DIR}/clibadjoint.py
+              ${CMAKE_BINARY_DIR}/clibadjoint_constants.py
+              DESTINATION lib/python${PYTHON_VERSION_MAJOR}.${PYTHON_VERSION_MINOR}/site-packages/libadjoint/
+        )
+# -----------------------------------------------------------------------------

=== modified file 'tools/create_python_constants.py'
--- tools/create_python_constants.py	2011-11-17 11:35:19 +0000
+++ tools/create_python_constants.py	2013-10-14 16:42:35 +0000
@@ -1,6 +1,19 @@
-#!/usr/bin/python
-
-f = open('include/libadjoint/adj_constants.h', 'r')
+#!/usr/bin/env python
+
+import sys
+if len(sys.argv) > 1:
+    source_path = sys.argv[1] + '/'
+else:
+    source_path = ''
+print source_path
+
+if len(sys.argv) > 2:
+    target_path = sys.argv[2] + '/'
+else:
+    target_path = source_path
+print target_path
+
+f = open(source_path + 'include/libadjoint/adj_constants.h', 'r')
 constants = {}
 
 for line in f:
@@ -14,6 +27,6 @@
 
 code = 'adj_constants = %s' % repr(constants)
 
-fc = open('python/libadjoint/clibadjoint_constants.py', 'w')
+fc = open(target_path + '/clibadjoint_constants.py', 'w')
 fc.write(code)
 fc.close()