Justine Devin / gammalib

Adding @TEST_ENV_DIR@ to load library path ensures the correct loading of shared libraries in case that some libraries were installed in non-standard locations.

The second compilation for unit testing is no longer needed as we found a way to pass the wrapper libraries to the PYTHONPATH. This speeds up unit testing.

A symbolic link to the wrapper library directory is now created. Adding this symbolic link to the PYTHONPATH avoids the need for a second inplace compilation.

The Darwin kluge that consisted of linking statically with the GammaLib library for unit testing created a problem in the unit test when using the gcc compiler. Specifically, an exception thrown in purpose during the HealPix test was not caught.

It turned out that the problem was related to the static linking. Linking dynamically did not produce the problem. Furthermore, it also turned out that the Apple compiler also works using the dynamically linked library during unit testing. I have no idea why this was a problem before, but now it is no longer a problem.

I therefore removed the Darwin kluge of static linking.

Furthermore, a post-processing step was added that creates a symbolic link to the directory that contains the shared wrapper libraries. In that way, we do not need a double compilation anymore (before, we compiled once for the install and a second time for the unit test). This should now speed up the unit testing step.

The WITH_UNIVERSALSDK is needed in setup.py to know when the MACOSX_DEPLOYMENT_TARGET environment variable should be removed.

…universalsdk has not been selected.

The export of MACOSX_DEPLOYMENT_TARGET led to some problems when trying to compile GammaLib on Mac OS X using the MacPorts gcc 4.4 compiler. The problems were uncatched exceptions that occured in some of the unit tests. After some debugging I discovered (by chance) that commenting the export of MACOSX_DEPLOYMENT_TARGET solved the problem.

Going into the Apple documentation (http://developer.apple.com/library/mac/#technotes/tn2064/_index.html) it appears that weak linking could be the root cause of the problems. With the current configuration on the Mac OS X 10.6 system on which the tests were done, MACOSX_DEPLOYMENT_TARGET=10.4. Following Apple's documentation, weak linking is implement from Mac OS X 10.2 on. Not specifying MACOSX_DEPLOYMENT_TARGET will automatically set the version to 10.1, hence no weak linking will be used.

Although I'm not 100% sure that weak linking indeed was the issue, removing the export of MACOSX_DEPLOYMENT_TARGET also removed the problems. I thus moved the export of MACOSX_DEPLOYMENT_TARGET into the --enable-universalsdk block, i.e. the export will only be done of the --enable-universalsdk option is selected. It remains to be seen whether this is the wanted behaviour.

The export of MACOSX_DEPLOYMENT_TARGET led to some problems when trying to compile GammaLib on Mac OS X using the MacPorts gcc 4.4 compiler. The problems were uncatched exceptions that occured in some of the unit tests. After some debugging I discovered (by chance) that commenting the export of MACOSX_DEPLOYMENT_TARGET solved the problem.

Going into the Apple documentation (http://developer.apple.com/library/mac/#technotes/tn2064/_index.html) it appears that weak linking could be the root cause of the problems. With the current configuration on the Mac OS X 10.6 system on which the tests were done, MACOSX_DEPLOYMENT_TARGET=10.4. Following Apple's documentation, weak linking is implement from Mac OS X 10.2 on. Not specifying MACOSX_DEPLOYMENT_TARGET will automatically set the version to 10.1, hence no weak linking will be used.

Although I'm not 100% sure that weak linking indeed was the issue, removing the export of MACOSX_DEPLOYMENT_TARGET also removed the problems. I thus moved the export of MACOSX_DEPLOYMENT_TARGET into the --enable-universalsdk block, i.e. the export will only be done of the --enable-universalsdk option is selected. It remains to be seen whether this is the wanted behaviour.

The Apple gcc compiler requires the gomp_thread_attr global to be
defined when OpenMP functions are called without having any OpenMP
section in the code. This specific requirement is now detected in
the configure script using some dedicated test code, and the compile
definition HAVE_OPENMP_DARWIN_KLUGE is set that allows inclusion of
the appropriate code when needed.

Furthermore, the OPENMP_LIB_LDFLAGS is not set to -lgomp on Darwin
anymore as this appears not to be needed.

On Mac OS X using the Apple gcc compiler, we need to include gomp_thread_attr in case we want OpenMP support. Some code has been added to the configure script to detect this specific need, and only if this specific need is met the variable HAVE_OPENMP_DARWIN_KLUGE is defined in config.h. We use then this varaible to include (or not) the following sequence:
#ifdef HAVE_OPENMP_DARWIN_KLUGE
#include <pthread.h>
pthread_attr_t gomp_thread_attr;
#endif

Due to a copy-paste error, the global for the registry was identical to the global for the FileFunction. It is surprising that this did not produce an error. This has now been corrected. Proper global variables were introduced for the NodeFunction.

The former Mac OS X clang kluge did not set the OBJEXT variable correctly (it was left blank). This has now been corrected.

The configure script checked for Python, and added a Python include path for compilation even if Python bindings were not requested. Now, if Python bindings are disabled, no Python checks are performed. We still check for swig and the wrapper files for the record, but we also could disable this.

The duplication of this section led to compilation problems on Mac OS 10.6 using gcc 4.3 and gcc 4.4.

The compiler search order was changed to first check for clang. As this can lead to problems on system where an broken clang installation is present, we only want to search for clang first if we have a Mac OS X >= 10.7 system (this is the first system where Apple fully switched to clang).

The swig files are needed for building of the ctools bindings, hence we put back the distribution of these files.

Summarize bug fix changes.

On new Mac OS X systems (>=10.7) we should select by default the clang++ compiler instead of the g++ compiler. The order of the compilers was thus changed on the compiler search, so that clang++ is detected before g++. As most other systems have no clang++ compiler (at least for the moment), this should not distrube the g++ discovery on these systems.

Formerly, the GammaLib swig files were needed to build the ctools binding, and for that reason the swig files were installed globally. This is not needed anymore. We therefore do no longer install the swig files.

sum function checked failed for clang on i386.

General typemaps have been defined to access index arrays through Python tuples. Typical usage of these tuples is the access of matrix elements, FITS image pixels or table columns, of skymap pixels. In the long run, these generic typemaps should be used throughout the GammaLib project for easier maintenance.

Implement matrix access operators that use Python tuples. For handling of Python tuples, a special SWIG file names GTypemaps.i was created. This file has to be included to expose the typemaps to the interface.