[Bf-committers] Libs on windows?

[Chad Fraleigh]

On Thu, Jan 24, 2013 at 3:40 AM, Brecht Van Lommel
<brechtvanlommel at pandora.be> wrote:

> On Thu, Jan 24, 2013 at 2:18 AM, Chad Fraleigh <chadf at triularity.org> wrote:
>> iconv doesn't seem to be used for windows [blender] builds. The only
>> place I see it in the cmake config is for "if(APPLE)", and even then
>> it is only a -liconv entry (so a system lib I assume). So is this
>> something that isn't used anymore (and should be removed from
>> trunk/lib/win*), a windows lib added but never included in the cmake
>> config, or something that is needed by other lib (that I have yet to
>> try compiling) and gets inlined into their dll?
>
> It seems indeed this is not used anymore and was replaced by boost locale.

In the case where it is included, it seems iconv is for boost_locale
to use itself.
The portion of CMakeLists.txt:

		if (WITH_INTERNATIONAL)
			list(APPEND BOOST_LIBRARIES boost_locale-mt)
			set(PLATFORM_LINKFLAGS "${PLATFORM_LINKFLAGS} -liconv") #
boost_locale needs it !
		endif()


It is odd that boost_locale would need iconv for APPLE, but not other platforms.


>> Is OSL currently working for windows? When I enabled WITH_CYCLES_OSL
>> (in VS2008/32-bit) it crashes with some invalid pointer when I start
>> blender.
>
> It's working with the library in svn now, not sure why it crashes for
> you. Make sure to match all the build options from build.bat for OSL
> and OIIO.

This is with just the standard svn windows libs. I first noticed it
when I was attempting to test my lib builds (so I enabled a few of the
WITH_* settings that are OFF by default) and it crashed. So I
eventually put them all back to svn and did a fresh build (or at least
I thought I did) and still had the problem. After some trial and error
flipping WITH_* options it seemed to be the WITH_CYCLES_OSL one (via
some llvm callback in the stack trace).

The configure used was:

cmake -G 'Visual Studio 9 2008' -DWITH_OPENCOLLADA:BOOL=ON
-DWITH_LLVM:BOOL=ON -DWITH_CYCLES_OSL:BOOL=ON
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DWITH_INTERNATIONAL:BOOL=ON
-DCMAKE_BUILD_TYPE:STRING=Debug ../blender

Just to be sure I'm running another fresh build using only the svn'd
libs (at least this time I can go sleep while it runs, rather than
wait around for it like the rest [talk about tedious testing]).


>> Also, just wondering.. what determines if something goes in
>> blender/extern/ vs lib/xxxxx/?
>
> I think usually things go into extern if there is no maintained
> library can be expected to become a linux package, or if it's a small
> library. But there is no clear rule that is always applied.

I did notice that openjpeg is used in the build but no
lib/windows/openjpeg/ install. My first thought was "why doesn't
windows use it".. then I realized it was auto built in the extern
directory (I only ever saw libmv building there it since that one
takes so long). But I have noticed that openimageio can use openjpeg,
if available. So would including it in openimageio (and the things
that use it, like OSL) be worth moving it to lib/ (or openimageio to
extern/ [which also would pull in OSL], at the price of making it a
very heavy build)? This was the idea I had with making a script to
build all the libs, only just once up front (or when something
changed) for each developer's specific "build environment". So it
wouldn't not compile them _every_ time, like extern/, and not static
(except "when someone updates svn for a given build environment")
either, but half way between.


-Chad