On Thu, Jan 24, 2013 at 3:40 AM, Brecht Van Lommel <[email protected]> wrote:
> On Thu, Jan 24, 2013 at 2:18 AM, Chad Fraleigh <[email protected]> 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 _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
