[Bf-committers] CVS commit: blender configure configure.ac

Maarten Gribnau bf-committers@blender.org
Tue, 3 Dec 2002 21:56:36 +0100


--Apple-Mail-2-512254178
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed

>> * If someone is compiling for OSX on linux-x86, the header files may 
>> not
>>   necessarily be install{ed|able} in /.
>
> This is a very unlikely scenario, where would you get the libraries to 
> link against?  I'm not saying it's impossible, just that it's so 
> remote a possibility, it's not worthing stressing about. If some 
> lunatic wants to have a go (and can somehow get all the libraries they 
> need to link against onto a linux system), good luck to them, but let 
> that person fix the configure script. Looking at the current 
> configure, even the most common form of cross-compiling (hosted on 
> linux-x86 to build mingw-x86 win32 binaries) isn't supported.
Agreed and OSX for intel is a rumor that I haven't heard for a long 
time.

>> * Doesn't the [native] compiler have builtin paths variables or 
>> something
>>   to contain part of the path?  Like say, "/System/Library", so only
>>   "Frameworks/OpenGL.framework/Versions/A/Headers/gl.h" is needed in
>>   configure.ac?  Or, even better, just "gl.h"?
>
> This is correct, there is some extra magic done with include paths by 
> Apple's GCC. However, it's not perfect and requires you to get the 
> framework in first (via -framework OpenGL, say). What is really needed 
> is some autoconf macros that can deal better with frameworks. In the 
> sort term, however, we should at least be using:
>
> /System/Library/Frameworks/OpenGL.framework/Headers
>
> Using the Version/A path is wrong and defeats Apple's ability to 
> upgrade the framework without breaking blender (the top level of the 
> framework will always contain symlinks to the current version, whether 
> that's A, B or something else)
Agreed again, the -framework OpenGL is the best solution on OSX. Why 
isn't it possible to do this with autoconf?
There is one downside to the -framework option. An include statement 
like
#include <gl/gl.h>
doesn't work. You need to include <gl.h> which means you need to wrap 
all OpenGL includes with a define, ugly...

The full path is fine for now, especially since the path is valid for 
all OSX users.

Maarten
--Apple-Mail-2-512254178
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

<excerpt><excerpt>* If someone is compiling for OSX on linux-x86, the
header files may not

  necessarily be install{ed|able} in /.

</excerpt>

This is a very unlikely scenario, where would you get the libraries to
link against?  I'm not saying it's impossible, just that it's so
remote a possibility, it's not worthing stressing about. If some
lunatic wants to have a go (and can somehow get all the libraries they
need to link against onto a linux system), good luck to them, but let
<italic>that</italic> person fix the configure script. Looking at the
current configure, even the most common form of cross-compiling
(hosted on linux-x86 to build mingw-x86 win32 binaries) isn't
supported.

</excerpt>Agreed and OSX for intel is a rumor that I haven't heard for
a long time.


<excerpt><excerpt>* Doesn't the [native] compiler have builtin paths
variables or something

  to contain part of the path?  Like say, "/System/Library", so only

  "Frameworks/OpenGL.framework/Versions/A/Headers/gl.h" is needed in

  configure.ac?  Or, even better, just "gl.h"?

</excerpt>

This is correct, there is some extra magic done with include paths by
Apple's GCC. However, it's not perfect and requires you to get the
framework in first (via -framework OpenGL, say). What is really needed
is some autoconf macros that can deal better with frameworks. In the
sort term, however, we should at least be using:


/System/Library/Frameworks/OpenGL.framework/Headers


Using the Version/A path is wrong and defeats Apple's ability to
upgrade the framework without breaking blender (the top level of the
framework will always contain symlinks to the current version, whether
that's A, B or something else)

</excerpt>Agreed again, the -framework OpenGL is the best solution on
OSX. Why isn't it possible to do this with autoconf?

There is one downside to the -framework option. An include statement
like

#include <<gl/gl.h>

doesn't work. You need to include <<gl.h> which means you need to wrap
all OpenGL includes with a define, ugly...


The full path is fine for now, especially since the path is valid for
all OSX users. 


Maarten
--Apple-Mail-2-512254178--