Build fixes for Visual Studio

These are source code changes to get OSL compiling on windows with visual studio (2008). There is still a big problem in generating llvm bitcode, and there are also some changes to make in the cmake files, but I have no solutions for those things yet.

Overview of the changes:

Renamed DLLPUBLIC because it conflicts with the OIIO define. Now there's a different define per OSL library, because they also conflict with each other, oslcomp use files from oslexec and vice versa. Sprinkled these defines in the header files where necessary, and put #include "export.h" in oslconfig.h.

Replaced all the platform specific hash stuff symtab.h with OIIO hash, which then compiles on windows too.

Compatibility fixes for popen/pclose, snprintf, RGB, access, strtof, and use of 'and' operator.

Code tweaks to handle spline template compile error, and double/float overloading problem with fmod.

Use "OpenImageIO/fmath.h" instead of <cmath> to fix missing M_1_PI and similar defines.

Use ${OPENIMAGEIO_INCLUDES} instead of ${OPENIMAGEIOHOME}/include for LLVM, as was already used for all other files. Avoids having to define the environment variable.

[larrygritz, 2011-03-01 00:43:12]

LGTM, pending answers to my two inline comments.

I don't even have access to a Windows box, so I'm taking your word for it that
these are all the right things for Windows compilation.  But nothing here looks
like it can harm the Linux/OSX users, so it's fine by me.

Brecht, have you sent us a CLA?  You can find it at
http://code.google.com/p/openshadinglanguage/downloads/list
just print, sign, scan, and email to opensource@imageworks.com.

http://codereview.appspot.com/4236041/diff/34001/src/liboslexec/splineimpl.h
File src/liboslexec/splineimpl.h (right):

http://codereview.appspot.com/4236041/diff/34001/src/liboslexec/splineimpl.h#...
src/liboslexec/splineimpl.h:118: BTYPE zero = 0.0f;
Why is this helpful?

http://codereview.appspot.com/4236041/diff/34001/src/liboslexec/vol_subsurfac...
File src/liboslexec/vol_subsurface.cpp (right):

http://codereview.appspot.com/4236041/diff/34001/src/liboslexec/vol_subsurfac...
src/liboslexec/vol_subsurface.cpp:29: #include "OpenImageIO/fmath.h"
What is the benefit of all changes changes of <cmath> to "OpenImageIO/fmath.h"?

[larrygritz, 2011-03-01 00:44:03]

On 2011/03/01 00:43:12, larrygritz wrote:
> src/liboslexec/vol_subsurface.cpp:29: #include "OpenImageIO/fmath.h"
> What is the benefit of all changes changes of <cmath> to
"OpenImageIO/fmath.h"?

Never mind, I should have read your comments more carefully.  I see why you did
this now.

[larrygritz, 2011-03-01 00:44:49]

If nobody else objects, I'm happy to commit this as soon as we get a CLA.

[brechtvl, 2011-03-01 01:09:21]

> Brecht, have you sent us a CLA?  You can find it at
> http://code.google.com/p/openshadinglanguage/downloads/list
> just print, sign, scan, and email to mailto:opensource@imageworks.com.

I'll send it tomorrow.

> http://codereview.appspot.com/4236041/diff/34001/src/liboslexec/splineimpl.h
> File src/liboslexec/splineimpl.h (right):
> 
>
http://codereview.appspot.com/4236041/diff/34001/src/liboslexec/splineimpl.h#...
> src/liboslexec/splineimpl.h:118: BTYPE zero = 0.0f;
> Why is this helpful?

There was a compile error with the template where it couldn't resolve things
correctly. I couldn't work out why it happens, but this change seems to fix it.
I can dig up the exact compile error tomorrow if you want.

By the way, I got everything working now on Windows, needs some changes in the
compiler and llvm code gen that are less straightforward but hopefully not too
bad, will send patches for that later.

[brechtvl, 2011-03-01 18:12:28]

Different fix for splineimpl.h

[brechtvl, 2011-03-01 18:17:40]

CLA sent.

It turns out the problem in splineimpl.h is because BTYPE is a macro on Windows,
so instead renamed it to ETYPE.

[ckulla, 2011-03-01 18:44:04]

On 2011/03/01 18:17:40, brechtvl wrote:
> CLA sent.
> 
> It turns out the problem in splineimpl.h is because BTYPE is a macro on
Windows,
> so instead renamed it to ETYPE.

Is it possible to just #undef BTYPE if its defined? Surely its nothing of value
to this file. It looks a bit strange to have ATYPE,ETYPE,CTYPE,DTYPE ...

[larrygritz, 2011-03-01 18:52:33]

On 2011/03/01 18:44:04, ckulla wrote:
> Is it possible to just #undef BTYPE if its defined? Surely its nothing of
value
> to this file. It looks a bit strange to have ATYPE,ETYPE,CTYPE,DTYPE ...

Agreed, I like the #undef BTYPE solution better too.

[brechtvl, 2011-03-01 19:31:01]

Alright, added patch with #undef BTYPE.

[ckulla, 2011-03-01 19:44:22]

A few more small comments ...

http://codereview.appspot.com/4236041/diff/49003/src/liboslexec/bsdf_cloth.cpp
File src/liboslexec/bsdf_cloth.cpp (right):

http://codereview.appspot.com/4236041/diff/49003/src/liboslexec/bsdf_cloth.cp...
src/liboslexec/bsdf_cloth.cpp:29: #include "OpenImageIO/fmath.h"
OpenImageIO is an external library, so it should be included with <> instead of
""

(I know the existing code isn't very consistent about this)

http://codereview.appspot.com/4236041/diff/49003/src/liboslexec/shadingsys.cpp
File src/liboslexec/shadingsys.cpp (right):

http://codereview.appspot.com/4236041/diff/49003/src/liboslexec/shadingsys.cp...
src/liboslexec/shadingsys.cpp:52: #ifdef _MSC_VER
Same comment here - should this be #ifdef RGB?

http://codereview.appspot.com/4236041/diff/49003/src/liboslexec/splineimpl.h
File src/liboslexec/splineimpl.h (right):

http://codereview.appspot.com/4236041/diff/49003/src/liboslexec/splineimpl.h#...
src/liboslexec/splineimpl.h:33: #ifdef _MSC_VER
Is BTYPE always defined? Or is it there because some other header is pulling in
windows.h?

Would it be safer to just say #ifdef BTYPE ?

[brechtvl, 2011-03-01 19:58:38]

The defines are indeed from windows.h. Latest patch changes the #ifdef tests and
uses <> for OIIO includes.

[ckulla, 2011-03-01 20:12:13]

On 2011/03/01 19:58:38, brechtvl wrote:
> The defines are indeed from windows.h. Latest patch changes the #ifdef tests
and
> uses <> for OIIO includes.

LGTM

Thanks for this patch! We'll make sure it still builds OK with our
configurations and apply it asap.

[larrygritz, 2011-03-01 22:39:24]

Committed as r898.

Thanks, and I'll add that a few times people have suggested a couple lines of
bug fixes here or there, this is the first nontrivial commit of code from
somebody not at all associated with Imageworks.  Congrats!