Re: [Openexr-devel] half

[darco]

On Monday, February 10, 2003, at 10:24 AM, Drew Hess wrote:
> OpenEXR libs may become a standard part of the system on Debian GNU/Linux, 
> for example.  Need to think about this and see what the GNU/Linux 
> filesystem standard says about it, at least.

On a related note, I have some thoughts regarding the way that the headers are set up in OpenEXR.

I would suggest putting the headers into a directory like this:

$INCLUDE_PREFIX/OpenEXR-$MAJORVERSION.$MINORVERSION/OpenEXR/

(That's all suppose to be one line, sorry if it wrapped)

Then add only the "$INCLUDE_DIR/OpenEXR-$MAJORVERSION.$MINORVERSION/" part to the include file search path. 

This would change the way that headers are included by outside programs:

#include <OpenEXR/half.h>

I think this would be a good thing. This setup allows you to install multiple versions of OpenEXR that have different ABI/APIs. It also prevents headerfile name collisions.

Another advantage to making this change is that it will also allow you to make OpenEXR into a framework on MacOS X. Frameworks require the name of the framework as the directory when using the header files, so if you want a program to compile with both the framework and with the normal library, you must include the headers this way.

I plan on making an OpenEXR framework at some point down the road. While I am doing most of my development on Linux, I want the code to be able to use the OpenEXR framework when I put it together later on. So I am already using the <OpenEXR/headername.h> format in my programs.

If you want to ensure compile-time backwards compatibility, you can include the whole 
"$INCLUDE_PREFIX/OpenEXR-$MAJORVERSION.$MINORVERSION/OpenEXR" in the header path as well -- won't hurt anything.

It might be better to break things down into different header "namespaces" like this:

$INCLUDE_PREFIX/OpenEXR-$MAJORVERSION.$MINORVERSION/OpenEXR/
$INCLUDE_PREFIX/OpenEXR-$MAJORVERSION.$MINORVERSION/IMath/
$INCLUDE_PREFIX/OpenEXR-$MAJORVERSION.$MINORVERSION/etc.../

And then have separate frameworks for each part.

These are just some thoughts... At some point I'll end up trying to cook up frameworks for MacOS X, and in the process also change how the include stuff is done -- so that I don't have to change the code to get it to compile with frameworks and also for the sake of having a cleaner, more organized filesystem for headers.

Regarding how to include files that are already in your library, I use the "filename.h" method rather than the <filename.h> method simply because it saves the time of typing out <libraryname/filename.h>. Of course, if you don't have the directories set up like that, then it doesn't really make a difference. Using the quotations in the libraries' header files also helps to emphasize that the header that you are referencing belongs to the same library.

--- darco
http://www.deepdarc.com/