On Sat, 7 Mar 2009 21:31:25 -0500 Brad <[email protected]> wrote:

> On Saturday 07 March 2009 21:04:05 J.C. Roberts wrote:
> > For some unknown reason, the folks at openexr mistakenly want to
> > #include their header files as <SYSTEM> headers rather than "local"
> > headers. Though this mistake is made often, it's not consistent.
> > It's even inconsistent within single files.
> >
> > The fast and dirty answer is to just -I* the directory where the
> > header files are located, but if they were written correctly, this
> > should not be necessary, so I took the time to patch them all.
> >
> > With anoncvs access, I think I did the diff correctly:
> >     $ cvs add patches/*
> >     $ cvs diff -uN >~/openexr.diff
> >
> > Since existing patches were skipped by the `cvs add`
> >
> > I'll try to get this upstream.
> >
> > -jcr
> 
> I'm very skeptical of this change. You haven't even explained what it
> is that you're trying to "fix".
> 

The various openexr headers all get installed in a single directory
(/usr/local/include/OpenEXR/) and many of them mistakenly include each
other via system header syntax:

        #include <whatever.h>

Since they are not actually system header files, the other OpenEXR
headers included are not found. Using the "" syntax says look in the
directory of the file being currently processed, but using <> syntax
looks for file along the defined system header paths (i.e
/usr/include, /usr/local/include, ...).

http://gcc.gnu.org/onlinedocs/cpp/Include-Syntax.html

For example, if any other port properly includes a problematic OpenEXR
header file as:

        #include <OpenEXR/ImfHeader.h>

the other OpenEXR headers included by OpenEXR/ImfHeader.h are not found
because they are not system header files (i.e. not located on the system
header paths).

This mistake means correctly written ports/software are forced to use
an -I option to specify the /usr/local/include/OpenEXR directory. Since
it's much easier to just toss an -I on the build, no one has bothered
to fix the mistakes. The only reason why we haven't hit a conflict
(i.e. the wrong header being included due to the system search path
oder) is due to the rather unique names of most of the openexr headers.

I hope this makes sense.

BTW, I dusted off the macppc system last night and it powers up! I
swapped out the hard drive (MacOS-9.1) and will get to installing
OpenBSD later tonight for x264 testing.

-- 
J.C. Roberts

Reply via email to