Andreas Zieringer wrote: >> Well.... Should be somehow on the wiki I think. What about the debug build? >> > > it was quite complicated to compile a release version of openexr so my > motivation to create a debug lib was quite low, what happens if you link > against the release version? > >
I don't remember but I got linking errors.... >> Can I just make the exr variable point to my own OpenEXR directory? >> > > yes. > > >> Would that >> work (I'm using the v1.4.0...)? Sorry but I was a bit upset because changing >> the scons command line means recompilation of the whole thing and that takes >> several hours on my machine. So yesterday night I was mainly waiting for >> OpenSG to compile.... Hopefully this will be better in 2.0. >> Anyway, my feeling is that the build should work out of the box (after >> having fulfilled all the preconditions documented on the wiki). So I >> reckon setting exr=no as default would be a good idea :-) >> > > well it works out of the box just the unzipped supportlibs on your > machine were not up-to-date. Perhaps it is possible to write some python > code to detect this. Ok the brute force solution is to unzip it everytime. > I unzipped the supportlibs bofeore building.... I think it would be better to have that as an external dependency. The OpenExr packages are very good to handle/use/install. So again, I'd rather set exr=no as default and let the debug build link to the debug exr build supplied by the user. Or fix the scons build as you suggested ;) Regards, Toni ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
