[petsc-dev] How to deal with OS-specific include paths?

[Barry Smith]

  Apple really sucks:

#if defined(__APPLE__) || defined(MACOSX)
#include <AvailabilityMacros.h>
#include <OpenGL/gl.h>
#include <OpenGL/glu.h>
#else
#include <GL/gl.h>
#include <GL/glu.h>
#endif


 OpenGL/gl.h doesn't mean the include is in the directory /usr/include/OpenGL  it means that the OpenGL includes is in the OpenGL framework so cannot be dealt with in the usual way by -Isomething.

I hate to have any ugly macro and have in the source code something like

#include OpenGLinclude 

I am fine with 

#if defined(__APPLE__) || defined(MACOSX)
#include <AvailabilityMacros.h>
#include <OpenGL/gl.h>
#include <OpenGL/glu.h>
#else
#include <GL/gl.h>
#include <GL/glu.h>
#endif

with configure first testing that they work.

   Barry


On Mar 18, 2013, at 6:22 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> 
> On Mon, Mar 18, 2013 at 6:17 PM, Karl Rupp <rupp at mcs.anl.gov> wrote:
> some packages such as OpenCL and OpenGL may be located in different subfolders depending on which OS we're on:
>  Mac OS: OpenCL/*.h   and    OpenGL/*.h
>  other:      CL/*.h   and        GL/*.h
> How is this properly translated into BuildSystem-specific package files? In opengl.py I only find
>     self.includes          = ['OpenGL/gl.h']
> and I can confirm that it fails to find the headers on my machine (Linux Mint). However, if I change the line in opengl.py to ['GL/gl.h'], everything works as expected.
> 
> We test each variant until we find one that works. I don't think there is an automatic way to do that currently so you'd have to call checkCompile() in sequence.
>  
> So, the question is: How to deal with these OS-specific things? Within header files there is the standard
>  #if defined(__APPLE__)
> 
> We (almost) never do this in the C file because it's fragile and fails too late. Instead, configure would normally test and set a macro indicating how to do it safely.
>  
> approach, but how does this translate to BuildSystem?
> 
>