On Sat, Jan 19, 2013 at 9:59 AM, Brecht Van Lommel <brechtvanlom...@pandora.be> wrote: > Great work! So have you been able to build Blender with these > libraries, does it need build system changes too or do things get > installed in the same directory structure as before?
I haven't tried them with blender itself yet. Right now I'm still trying to verify that others can repeat the builds without the same compile errors that were experienced on my earlier script releases. I suppose I could copy some into my normal blender lib/ directory and try a few. It wasn't until I did openimageio that I realized that boost was still compiling 32-bit mode (even though I was giving it a 64-bit compiler environment). Right now I've gone back to building only the static libs (where it easily let me) to reduce static/dynamic conflicts. But I was wondering if eventually using the dynamic ones for most in blender would be of value? I see it has some dll's in the blender install, but not many. Since not much would be sharing the libs (really only moving stuff from blender.exe to dll's), it may just be extra work with no real benefit. Maybe the thumbhandler could share some (why _can't_ its code be in the normal build area again??) > So let's see how we can get this stuff in svn. Can we get some > feedback from Windows platform maintainers, do you all agree with the > general idea here? Does anyone want to review the scripts and setups > here? Just a note -- the makefile is still ugly. Eventually I would like to move the section for each lib to it's own .mk file with the base one including them all, or each being a standalone make (and including a .mk for common parts), rather than the monolithic thing it is now. > The question then is also still what kind of directory structure we > want to use for windows libraries. In my opinion we should just have a > lib/windows-arch-vsxxx directory for each combination we support. This > gives a minimal and simple download for users. The include directories > would be duplicated, but that's also an advantage if not all platforms > get updated to a new library version at the same time, otherwise the > build might break. That's what I had in mind also.. since there is already include duplication with the x32-vs-x64 and mingw, it wouldn't be a major change (and the cmake config for blender itself would be simplified -- just configure the base lib path). There would be a few binary duplicates for the few packages that won't compile under VS (due to no vs/cmake config, C99 support, or just being fortran *grin*). I might try to write cmake files for the simple cases (but then someone would need to tweak them with each new lib version). The 'jack' and 'sndfile' libs are the only ones I've found [so far] with predictable sources of precompiled ones for both 32-bit and 64-bit for the VS-no-go list. Also I include a VERSION.txt file (and LICENSE.txt when I can find one in the source) in the install directory for each.. one for license compliance and the other since it is sometimes hard to tell what version a lib is (sometimes in the lib name, sometimes in a header, other times haven't a clue). I appended the .txt part since it might be easier for windows users to open [via double-click] (not counting it running notepad and the file having unix newlines). If these files are added for the other platforms it would be nice to make the names the same (be it with or without the extension). Oh, and the VERSION[.txt] file is always installed last -- so it can be used as a generic "is this lib completely here" test. Also, I don't know what is done now but I think a library manifest (just a txt file would due) that lists all the external libs bundled with blender and their versions to be included with each release so if there are any concerns about security issues with those libs, one can also look at the list. This of course can be pulled from the VERSION.txt files during the blender build. Speaking of mingw.. eventually I would like to have support for that in the builder (not the same makefile since this is nmake specific), but another makefile or script that does those environments (and maybe osx and/or android). It could use any common resources like the source zip/tar distros, and maybe the patches where applicable. -Chad > On Sat, Jan 19, 2013 at 6:47 AM, Chad Fraleigh <ch...@triularity.org> wrote: >> After some more work, a few breaks to avoid insanity fighting with >> some of the VS and cmake configs, and a lot of hacking of the various >> build scripts/projects (the patches it has to do is a mess!), I got >> farther. Now I'm able to build all the following libs under >> VS2008/32-bit, VS2010/32-bit, VS2010+SDK7.1/32-bit, and >> VS2010+SDK7.1/64-bit: >> >> boost >> freetype >> ilmbase >> jpeg >> lcms >> llvm >> openal >> opencollada >> opencolorio >> openexr >> openimageio >> png >> pthreads >> python >> samplerate >> sdl >> tiff >> tinyxml >> yaml >> zlib >> zlibwapi >> >> I'll try to install the 6.1 SDK soon and see if it also works for >> VS2008 x64. Unfortunately when I reinstalled my VS's, VS2012 decided >> to manifest a bug where it doesn't install any of the C header files >> (thanks M$!).. so I can't do any more testing on them at the moment. >> >> The builder setup (with and without source tar/zip distros): >> >> http://www.triularity.org/download/blender/lib-builder.zip (186M) >> http://www.triularity.org/download/blender/lib-builder-nosrc.zip >> (4.5M) >> >> The results of my compiles (the VS10+SDK7.1 x32 was omitted due to >> size and being mostly redundant if someone just needs the 2010 >> binaries). >> >> >> http://www.triularity.org/download/blender/install-vs9.0_x32_sdk6.0.zip >> (217M) ** >> >> http://www.triularity.org/download/blender/install-vs10.0_x32_sdk7.0.zip >> (214M) >> >> http://www.triularity.org/download/blender/install-vs10.0_x64_sdk7.1.zip >> (254M) >> >> ** install-vs9.0_x32_sdk6.0.zip is still uploading as of composing >> this message, so give it half an hour or so if you want that one. >> >> The logs for each of those builds (generated by the buildall.bat >> script) for reference: >> >> http://www.triularity.org/download/blender/logs-vs9.0_x32_sdk6.0.zip >> (275K) >> >> http://www.triularity.org/download/blender/logs-vs10.0_x32_sdk7.0.zip (471K) >> >> http://www.triularity.org/download/blender/logs-vs10.0_x32_sdk7.1.zip (472K) >> >> http://www.triularity.org/download/blender/logs-vs10.0_x64_sdk7.1.zip (498K) >> >> All the old install-*.zip's have been deleted (to free up space). >> >> >> -Chad _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers