Build binaries for windows for 1.0 - also make windows HDF5 calls multithread safe about alembic HOT 35 CLOSED

when building the HDF5 libraries on windows, the thread-safe option has more 
dependencies and build steps to go through before it can be built successfully.

in the release_docs/INSTALL_Windows.txt file you will find the extra 
dependencies and build steps in detail, but essentially you will need 
pthreads-win32 library compiled for 64bit.

i am keeping a set of notes of my adventures building on windows, once i get 
pthreads-win32 built on windows i will post the necessary information... if any.

Issue 81 has been merged into this issue.

you will need to build pthreads from source, the latest source package fails on 
windows 64bit. information about the cvs repository can be found here...

http://sourceware.org/pthreads-win32/

i read somewhere that using pthreads on windows doubles the memory usage!? lets 
hope its not an issue.

Hmmm...  Perhaps we can evaluate building HDF5 without thread safety.  I found 
this message, which was intriguing:

http://mail.hdfgroup.org/pipermail/hdf-forum_hdfgroup.org/2010-March/002802.html

A native hdf5-group solution like this would be ideal, but we definitely 
wouldn't want to rely on maintaining our own fork of HDF5.

Changing priority in relation to 1.0

ok, i recently updated from joe's development clone and i am getting this build 
error when building AlembicAbcGeom...

.../AbcGeom/OSimpleXform.h(164) : error C2864: 
'Alembic::AbcGeom::OSimpleXformSchema::ODefaultedDoubleProperty::SIMPLE_XFORM_DE
LTA_TOLERANCE' : only static const integral data members can be initialized 
within a class

a little research into the subject leads me to this...

http://stackoverflow.com/questions/370283/why-cant-i-have-a-non-integral-static-
const-member-in-a-class

there are a few different suggestions, but the suggested the most is to declare 
in the header file but define in a source file. i did so and i have made my 
first windows specific source code modification, but i dont know if this change 
is the proper way to make it portable. i am going to make the google hosted 
windows dev clone and push the change to that repo for review.

i am not sure of the proper way for offsite people to post reviews, any 
guidance on the matter would be appreciated. until then, small cmake adjustment 
to avoid the 'Command line error D8021 : invalid numeric argument '/Werror' on 
windows. i have yet to find the proper windows equivalent, if there even is 
one. 

https://code.google.com/r/carons-windows/source/detail?r=02f01b748c54ff7e8d5daec
5db84b83145941043

fix for 'only static const integral data members can be initialized within a
class' error happening on windows. i can compile AlembicAbcGeom now...

https://code.google.com/r/carons-windows/source/detail?r=91852575ce40ccd365c4e3b
1f6c4f9a8140aef17

'AlembicGLUtil' will need some love to get it compiling out of the box on 
windows. i was able to build by changing the includes to point to windows 
variants of the header files, copying around some header files, and adding some 
additional include directories for glew and glut.

at first glance 'GLUtil\Foundation.h' needs specific windows preprocessor 
conditions for the correct include files. also the windows user will need to 
get satisfy some dependencies, glew and glut. this information should be added 
to the windows build notes. lastly, some additions to the cmake files to add 
these include/lib directories to the generated project would help windows 
building experience.

added the preprocessor conditions...

https://code.google.com/r/carons-windows/source/detail?r=205ba36c6384380ae845981
a68db6a2fdbbca253

Hey, thanks again for the work!  I've moved the definition of 
SIMPLE_XFORM_DELTA_TOLERANCE outside of the class; there's no real need for it 
to be a class member.  It's still in OSimpleXform.h, inside the 
Alembic::AbcGeom namespace, and has been renamed to 
"kSIMPLE_XFORM_DELTA_TOLERANCE".

In the top-level CMakeLists.txt, I've put the compiler directive for "-WError" 
to be inside an "IF( NOT WINDOWS )" block, rather than "IF( LINUX )", since 
we'll still want that for OS X ("DARWIN").

In GLUtil/Foundation.h, I've added the following:

#ifdef WIN32
#include <GL/wglew.h>
#endif
#ifdef WIN64
#include <GL/wglew.h>

#else

#include <GL/glxew.h>
#include <GL/gl.h>
#include <GL/glu.h>
#include <GL/glext.h>
#include <GL/glut.h>

#endif // ifdef WIN64

#endif // ifdef PLATFORM_DARWIN

You can see the changes I've made here:

http://code.google.com/r/ardent-embic/source/detail?r=83782174441eee0e100c06f86c
13c856ce28279f

and here:

http://code.google.com/r/ardent-embic/source/detail?r=8e074a5c8948eef379e2e59eb2
ea206ec296d9d9

thanks for the review and improvements, i will pull from your repo when i 
continue working.

i was able to build all core alembic libraries, but nearly all the tests that 
actually use alembic still failed. they are all linker errors and i suspect its 
showing me issues with my earlier build steps and/or project settings. i get a 
lot of unresolved external symbols and issues with symbols already being 
defined in other obj files. lots of work still ahead!

since i am on windows IlmThread doesn't build with pthread/semaphore. is this 
an issue? i would assume IlmThread abstracts any differences between threading 
in a linux environment and a windows environment, but there maybe lack of 
support for certain things with IlmThread on windows? i could be way off base 
with this.

Hey Steve, I wanted to let you know that I've fixed 32-bit support for Alembic. 
 If you want, pull from my dev clone (ardent-embic), and you'll get it.  I'll 
probably bring those changes into the main repo today or tomorrow.

But, this means we don't need to work so danged hard to get HDF5 working with 
64 bit on Windows :)

Simple question, is this done? 

no its not, sorry. i am no build engineer, so i don't know what the issues are 
anymore. i might try with 0.9.2 soon, but i suspect the issue isn't with 
alembic but with all its dependencies. making sure they all compile with the 
correct configurations.

if you are a developer, maybe you could give it a go with the latest 0.9.2?

Actually, there's some news on this front!  One of the engineers here just 
yesterday managed to get everything built on Windows, and all the tests pass.  
As intimated, the most difficult part was building HDF5.  He's going to clean 
up his build setup a bit, then give me a detailed recipe for doing this.  I'll 
post that to the alembic-discussion list (and here) once I get that.

ah, great news joe! i wasn't 100% sure it was hdf5 but i had a gut feeling it 
was related to threading configurations on the different platforms.

Excellent, thanks

Community interest and efforts lead me to think that for 1.0 release we should 
make sure the library still builds on windows. I suspect will either just work 
or only require small effort (e.g. 1 day)

For 1.0 due to the amount of effort it takes to build on windows we will 
rebuild Alembic libraries and the command line tools and maya plugins, Ri 
procedural, and houdini plugins (this seems to imply we'll do windows vista and 
32 and 64, and maya 2011 and maya 2012 - though I'm guessing for this list). We 
want to do something "reasonable".

We are moving this to a milestone 1.1 release item.

Also, I am assigning this to Erik as he was going to follow up with one of our 
partners about their well done Windows implementation.

Thanks, Scott

Bumping prio, as we need windows build support and community needs this. Joe 
had begun this work, spent a week on it, but ultimately did not succeed.
See lots of recent traffic on mailing lists - long thread, but for example:
------
Helge Mathee [email protected]  to alembic-discus.

I have changed the repo to

http://code.google.com/r/helgemathee-alembic-softimage/

Joe was claiming that HDF5 isn't multi thread safe on windows, however I think 
he just missed this part on the HDF5 web side under the FAQ:
---
Can I use thread-safe feature on Windows?

Yes, we do support this feature. Please see the details in section "How to 
build HDF5 with Thread-Safe Feature", in the document INSTALL_WINDOWS.txt

the 2nd - 5th post on this thread mentions pthreads, its potential to cause 
memory consumption to double, and joe's research on the hdf5 list mentioning 
someones experimental support for thread safety with out the dependency.

Moving to 1.0.2 point/patch release

Moving to 1.0.3. Can move back if we need to.

Closing these old tickets out.  Please reopen new tickets if they are relevant 
to you and not completed satisfactorily.