CMake 2.8 doesn't search /usr/include/SDL2, which is the include directory
for SDL 2.x on Ubuntu Linux (and possibly others). This results in SDL 1.2
headers being found when WITH_SDL_DYNLOAD=OFF, and our shipped SDL 2.0
headers when WITH_SDL_DYNLOAD=ON. This patch ensures that in both
cases the correct SDL headers are used.
Reviewers: sergey, campbellbarton
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1112
Generally for build systems, libraries that do not depend on other
libraries, such as system libraries, OpenGL etc always go at the end.
We could even get rid of some duplicate dependency libraries here but
auto duplication by build systems and differences between OSs make this
difficult.
GTest still duplicates all libraries twice to solve some issues which is
weird (maybe libs are not sorted correctly for some reason? needs
investigation)
Basic idea is to check whether OIIO is compiled with embedded PugiXML parser
and if so use PugiXML from OIIO, otherwise find a standalone PugiXML library.
Weird library names having version suffix (e.g. libIex-2_1.so) are used only
when the OpenEXR was built with CMake. Building the library with the Autotools
doesn't add the version suffix.
Note that I also updated OpenEXR to 2.1.0 (and updated our CMake openexr module as well).
Users will have to update their build settings as told by the script (also in BUILD_NOTES.txt generated file)!
Note I removed all ugly patches from this script, we are currently using custom git repo for OpenEXR/OIIO/OSL,
hopefully we will soon be able to use vanillia code from official repos!
As OSL headers mix #include <OpenEXR/foo.h> and #include <foo.h>, we need both /path/to/openexr/include and /path/to/openexr/include/OpenEXR include paths... :/
Issue investigated by doug65536 on IRC, thanks.
Mostly, it:
* Adds numpy and opencollada
* Merges both Suse and Fedora/Redhat into a single func (not sure this is a good idea, but would have been to painful to undo this).
Notes:
* I changed a bit how numpy is handled, so that the script does not try to build it when py3.3 was installed from package!
* Bumped oiio 'magic number', as now trying to use libtiff5 means we have to rebuild everything using tiff!
* Only made a quick test on my own system, but Ejner made quite some extensive ones, so it should be safe.
* I’m not sure keeping on extending that horrible bash thing is a good idea. Shell scripts are nice for small, limited stuff, but I personnaly find that one (over 53ko!) unreadable and a pita to maintain. Further more, doing the same for windows would mean to rewrite everything in another language... I have started work to port this as a py3 script, so that we have a nice structure (classes...) easy to extend/tweak/implement in various OSs/etc.!
This script will install all packages from the repositories and will compile
missing in repositories libraries.
It is supposed to replace pre-compiled libraries from our svn.
Tested script on Fedora 14 and 17, Ubuntu 10.04 and 12.10. All the dependencies
and manually built libraries seems to be fine. However, it's really annoying to
build blender in virtual machine to ensure there's no linking errors, i would
hope community will help testing and making needed tweaks to the script :)
To use the script, simple run it from your user name. It'll run installation
commands from a sudo, so you would likely be requested to type a password.
I've made tweaks to CMake FindLibs, so it should find OIIO, OCIO and python
libraries compiled by this script. Boost and FFmpeg would need to be specified
manually.
SCons currently would require manual paths specifications as well. Perhaps we
could make SCons smarter in the future.
All the parameters you need to pass to CMake/SCons would be printed when script
finishes to run.
Pretty much sure it's not production-ready script, but we need to start testing
at some point :)
This commit integrates support of OpenColorIO library into build systems.
It also contains C-API for OpenColorIO library which could be used by Blender.
CMake has got find rules familiar to OpenImageIO's one which makes it easier
for build system to find needed libraries and includes. Scons only could use
explicitly defined paths to libraries and includes.
C-API would be compiled and Blender would be linked against C-API and OpenColorIO
but it wouldn't affect on Blender behavior at all.
OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and
setting WITH_BF_OCIO in Scons.
made some small edits
- removed changes to AVI reading since the data types are apart of the format spec.
- absf -> abs for a double value in render code.
