openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] OpenEXR Windows port


From: Drew Hess
Subject: Re: [Openexr-devel] OpenEXR Windows port
Date: Fri, 24 Jan 2003 11:07:48 -0800 (PST)

Hey all,

Just so you know, I'm waiting for a patch from eyeon Software, who 
apparently have gotten OpenEXR to compile on Windows using VC++ 7.0/.NET.  
We may have to just punt on getting this to work with VC++ 6.0 (unless you 
use the Intel compiler) due to templating issues, but I'll know more when 
I get my own VC++ 6.0 box (soon, I hope).

I appreciate everyone's efforts trying to get this working on Windows.

Dustin, I'll take a look at your patches when I get my Windows box.  
Thanks!


-dwh-

p.s. a friend of mine got it to compile with Cygwin.  I haven't used 
Cygwin or Windows in a long time, but seem to recall that you can link 
Cygwin-generated libs against VC++-generated code.  Is that right?



 On Fri, 24 Jan 2003, E. Scott Larsen wrote:

> 
> > Re: [Openexr-devel] OpenEXR Windows port
> > From: Dustin Graves
> > Subject: Re: [Openexr-devel] OpenEXR Windows port
> > Date: Fri, 24 Jan 2003 00:22:12 -1000
> > User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;rv:1.2) 
> > Gecko/20021126
> > Last night I did a rough port to Windows with Visual Studio 6 + Intel 5.0 
> > Compiler. I was unable to use the compilers provided with both Visual 
> > Studio 6.0 and .NET because they do not recognize this as legal syntax:
> > 
> > template <class T>
> > template <class S>
> > inline bool
> > Vec2<T>::operator != (const Vec2<S> &v) const
> > ..
> > 
> > The template followed by a template causes a syntax error. This is a bug 
> > with the compiler, which I'll try reporting to Microsoft.
> 
> They already know about it and haven't shown any intention of fixing it 
> in the last 4 years (at least) since they've known about it.
> But I've figured out a work around, I'll start with your project files 
> and stuff (_thanks_ for those!) and see what I can do, I'll get back to us.
> 
> > But I was able to compile most of the code with the Intel compiler. 
> > Everything except IlmImfTest and ImathTest, because they use the drand48 
> > family of functions which are not provided with Visual Studio. The port was 
> > pretty simple, requiring few changes. The most prominent changes were:
> 
> I've got a full license for it, so it'll help (shouldn't mention here 
> that it is a superior compiler, so I won't).
> 
> > 1. typedef Int64 as __int64
> > 2. the numeric suffix UUL is not supported, and must be changed to UL
> > 3. std::min and std::max are unavailable (due to conflict with min and max 
> > in windefs.h), so std::_MIN and std::_MAX are provided instead.
> 
> I always undef those after including windows.h, but your solution looks 
> fine too.
> 
> > 4. Imath needed a preprocessor directive to indicate hypot should be used 
> > instead of hypotf
> > 5. Scoping error with variable declarations within 'for' loops, resulting 
> > in multiple defines, required variables to be declared outside of the 'for' 
> > loop, once per function.
> 
> again, non-spec compilers.  I've seen someone do this:
> {for (int i......){
>       //code
> }}
> so that all compilers scope the variable declaration properly.  It's 
> always worked where I work. (MIPSPro, gcc, MSVC, Intel)
> 
> //Scott
> 
> > 6. windows.h must be included before gl.h
> > 
> > I think that was pretty much it. I have put the VC6 project files, patches 
> > with the changes I made for the Windows port, and precompiled binaries 
> > (libs for Imath, Iex, Half, IlmImf, and an executable for exdisplay) on the 
> > web. You can find them at:
> > 
> > http://www.hawaiian.net/~dgraves/openexr/openexr.html
> > 
> > Also, Intel has a 30 day trial period for their compiler for anyone 
> > interested. You can optain it from their website. The installer will 
> > integrate it with Visual Studio, allowing you to select the compiler from 
> > the Tools menu. But, hopefully if the problem with templates and their 
> > template members is somehow resolved the Intel compiler will be unnecessary.
> > 
> > Dustin
> 
> 
> 
> 
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/openexr-devel
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]