CMake shared libraries

[danielkaneider]

Hi,

since I missed to compile OpenEXR Dlls using the CMake build system, I implemented some CMake options. Moreover I made the usage of the zlib-winapi version optional (via option), it works fine for me using the normal zlib version.
I needed to change a few files, fixing some export symbols, but finally it works. I tested it on windows 32+64bit Visual Studio 2012.

Since your CMake infrastructure looks quite stable, I strongly suggest removing all Makefiles and VS solutions from the repository.

Best,
Daniel Kaneider

[fnordware]

Thanks for your work. I'm glad to see ZLIB_WINAPI gone to a build option as it should be.

I like having the Visual Studio projects because it lets you build EXR libraries into another VS project just by adding the project files into your solution file.

Although I think the Visual Studio projects have not been updated for the new OpenEXR 2.0 stuff. Maybe I can help with that.

[danielkaneider]

The purpose of CMake is to generate VS projects when needed. I see no reason in keeping VS solutions from vc7 to vc9 in the sources. Without mentioning, that the solutions for vc10 and vc11 are missing...

[meshula]

The cmake parts look like a definite improvement, but it would be good to retain the export semantics for gcc, new namespacing macros, and so on. Maybe this change can be reconciled somehow with #54

[fnordware]

I see about VS projects. Well then yes, I agree, get rid of them. They're out of date anyway.

Too bad CMake doesn't make Xcode projects too.

[blackencino]

I think CMake does make XCode projects. It used to, at least, when we
started Alembic using it.

On Mon, Apr 15, 2013 at 5:13 PM, Brendan Bolles notifications@github.comwrote:

I see about VS projects. Well then yes, I agree, get rid of them. They're
out of date anyway.

Too bad CMake doesn't make Xcode projects too.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/57#issuecomment-16419282
.

I think this situation absolutely requires that a really futile and stupid
gesture be done on somebody's part. And we're just the guys to do it.

[meshula]

Cmake does good command line builds for OSX. The Xcode projects it makes are very clumsy unfortunately.

[pstanczyk]

Hi, I've created a separate branch for this : cmake-fixes and patched in the changes there.
Commits:
e29ffab
25ba461
6d30847
f38a591
7dcffff

Let me know if that works ok for you.

[danielkaneider]

Hi,

thanks, your namespace fix works for me.

Some notes to previous discussions: I simply tried to unify the export symbols in the header file. Unfortunately OpenEXR Headers are very inconsistent. For instance ImathExport.h, halfExport.h and IexMathFloatExc.h defined 3 different ways of creating export symbols. From those patterns I took the first one, and yes, I missed the point that the gcc visibility might be somehow important. Btw. from the 3 header files listed, just one included the gcc visibility attribute (before my patch).

For general unification #54 offers a good starting point, but more should be done. IMHO there should be just one header file which defines export symbols. Either all projects have *_EXPORTS and OPENEXR_DLL defined, or none. I don't think they should and will be mixed. Such a modification would also ensure that there are no different export definitions around.

Best,
Daniel