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

James Turner bf-committers@blender.org
Tue, 3 Dec 2002 10:28:07 +0000


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


On Tuesday, December 3, 2002, at 10:06  am, Frederick Lee wrote:
>
> Is it a good idea to keep the path as
> "/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers/gl.h"?
>
> Here are my gripes:
>
> * That path is a hard-coded absolute path.
Yes but well defined (and it's hard coded in configure.ac, not the 
source files)

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

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

H&H
James

--
We are all in the gutter, but some of us are looking at the stars.

--Apple-Mail-4-474545052
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII



On Tuesday, December 3, 2002, at 10:06  am, Frederick Lee wrote:

<excerpt>

Is it a good idea to keep the path as

"/System/Library/Frameworks/OpenGL.framework/Versions/A/Headers/gl.h"?


Here are my gripes:


* That path is a hard-coded absolute path.

</excerpt>Yes but well defined (and it's hard coded in configure.ac,
not the source files)


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


H&H

James


--

We are all in the gutter, but some of us are looking at the stars.


--Apple-Mail-4-474545052--