[Bf-committers] External libs builder for Windows [v2013.01.18]

[Chad Fraleigh]

On Sat, Jan 19, 2013 at 9:59 AM, Brecht Van Lommel
<brechtvanlommel at 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 <chadf at 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