Re: [Openexr-devel] submitting patches?

[J.C. Roberts]

On Wed, 11 Mar 2009 22:20:28 -0700 Piotr Stanczyk <address@hidden>
wrote:

> Hi  J.C.
> 
> Thanks for your time in addressing this issue. I wanted to sweep the 
> rest of the other modules to get an idea of how much work this would 
> entail.  This, from I can gather, has come up before in the context
> of building on windows and I've added it to our to do list.
> 
> We are currently at the end of identifying what outstanding work is
> to be done for the next release. A definite date has not been set for 
> release, but there is good momentum.
> 
> I'd like to download and archive the patches you mailed if that's
> fine with you.
> 
> Piotr

Hi Piotr,

The initial 45 patches in the archive on my server were done with the
typical filename.c <-> filename.c.orig method used for porting third
party software to all of the *BSD operating systems (i.e. software in
the "ports tree"). They will apply cleanly against OpenEXR 1.6.1, and
they will probably get them committed to the OpenBSD ports tree.

You can do whatever you like with my archive of initial patches, but I
think you might prefer if I pull the all current OpenEXR CVS modules,
and then diff against CVS?

At least for me, and the projects I work on, unified diffs against CVS
is the most common and accepted way to submit suggested changes. Since I
didn't know if these changes were even wanted, I didn't take the time to
either diff against cvs or scan for the bug in every header in the
entire OpenEXR tree (i.e. all modules). I only covered the *installed*
headers for OpenEXR-1.6.1 proper. Since I'm guessing diffs against CVS
is how you'll want things done, I've already started the checkout of
all the current OpenEXR cvs modules. If you'd prefer some other method,
please let me know.

I know OpenEXR was developed internally at ILM, but as open source, if
I want something changed, I should be willing to do the work myself,
and more importantly, why should I let you have all the fun? :-)

The "fun" of scanning and fixing all the header files is more drudgery
than difficult, but I already have a nice chunk of the work completed.
If you want to delegate the work, I can take care of the first step of
patching the various headers, in the various modules. After we are
certain there is no breakage from the first step, then I can assist you
with the second step of modifying the build system to prevent this
issue from happening again. 

At present, I'm not entirely certain we'll be able to modify the
build system to prevent this mistake with *all* compilers/preprocessors
but if we can get a few of the common ones to croak on the wrong syntax,
we'll at least find any new mistakes while testing. The trouble is, on
some compilers/preprocessors and/or system configurations it might not
matter if we remove the "-I." option from the build system because the
current directory is, by default, always in the list of paths searched
on `#include <SYSTEM>` syntax. As stated, the standards are not entirely
clear on this issue, and as always, implementations vary.

Though the release schedule is undecided, I can get the first step done
fairly quickly.

-- 
J.C. Roberts