Justine Devin / gammalib

An issue has been raied (#1098) to track solving the problem.

The testconf.sh.in script may be used to test the GammaLib configuration script following installation. This script should be used by the continous integration system to guarantee the coherence of the installation script at any time.

The configure option --enable-warnings now sets the definition G_WARNINGS in the config.h file.

The function gammalib::warning() has been added to GTools. The function dumps a warning to the console in a standard format if the warning option is enabled.

The function is now used in GFitsHeaderCard to dump any warning about invalid header card value types to the screen.

…ble in unit tests and use PACKAGE_SOURCE determine in configure instead of abs_top_srcdir as the latter does not exist on older systems.

…t is run. This directory will be used in unit testing for building absolute path names.

These environment variables have been probably removed in error from the script at some time.

The MWL module was checked conditionally and unconditionally. The unconditional check was an unintended, and has been removed.

On Ubuntu, the dlopen() test did not suceed, probably due to a wrong ordering of the compile flags (see Bug #548). Correctly, the LIBS environment variable should be used to specify the -ldl library (as in ctools). This has been corrected.

Appending /opt/local/bin to TEST_ENV_DIR, and hence to DYLD_LIBRARY_PATH did produce some problems on Mac OS X using MacPorts systems. Therefore, /opt/local/lib is no more appended.

For proper usage of the GBase class within Python, the base module is required.

Dependency tracking leads to a very agressive recompilation of the code. This makes development inpracticable.

A base module has been added to implement the os and GLog streamer at the base level. This has also be done for Python.

This option is needed to support swig dependency tracking.

I don't recall why dependency tracking has been disabled (maybe for speed reasons). I enable it to see whether any problem occurs. If no problem occurs and compilation speed is reasonable, I guess to leave it on.

Alternatively, one could introduce a developer configuration that switches dependenct tracking only on for developers.

Conflicts:
	configure.ac
	test/Makefile.am

Both conflicts have been resolved.

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

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.

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 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).

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.