Support for OSX Leopard and Solaris (using Sun Studio compiler)

[jbronn]

I wanted to get this out to the Mapnik community for discussion. This patch fixes issues with compiling on OSX Leopard (10.5) (specifically in unicode.cpp), and provides very rough support for the Sun Studio CC C++ compiler on Solaris. In the process, SConstruct was re-worked a bit and a SCons bug was fixed (was specific to Solaris-only).

As far as I know, this is the first attempt to use a C++ compiler other than g++ (with the exception of the MS Windows references I've seen sprinkled in the code). My C++ is a bit rusty, but this highlights some code with portability issues across compilers.

Some highlights of code that was troublesome for Sun's compiler:

• The following line in the Boost property_tree implementation gave errors about "the declaration needs to be within a statement":

  typename traits_type::template inserter<Type>()(m_impl->m_data, value, loc);
  

• In utils.hpp, the following lines (L83 and L92):

static void destroy(volatile T* obj)
...
friend class CreatePolicy<T>;

The Sun compiler raises errors about the use of the volatile keyword and that the friend class declaration "must specify a class or function."

• All of the inline declarations in envelope.cpp.

I also added the iconv library to the requisites (even though Artem patched for Darwin in r600) because it was required for both Leopard and Solaris.

[mloskot]

I'd like to share my 5 cents and comment the patch:

// When using Sun's C++ compiler, use the `std` namespace to get the math routines. 
#ifdef __SUNPRO_CC 
using std::fabs; 
using std::sqrt; 
#endif 

Actually, the problem with math routines is in the Mapnik. Mapnik does not use fully qualified names like std::sqrt but expects to find these functions in global namespace. If std:: prefix is added to the include/mapnik/geom_util.hpp file, then no extra fix for SUNPro is needed.

[mloskot]

BTW, similar issue is in the include/mapnik/global.hpp. It's a good idea to avoid using directive in header files, to not to polluted global namespace too much.

[springmeyer]

this patch was applied in r603, so closing this ticket.

If the issue mloskot raised still remains, perhaps we need another ticket about C++ namespaces?