from Lawrence D'Oliveiro (ldo)
Get rid of BLI_splitdirstring, replace with calls to BLI_split_dirfile, BLI_split_dir_part and BLI_split_file_part as appropriate.
now blenlib/BLI doesn't depend on any blenkern/BKE functions,
there are still some bad level includes but these are only to access G.background and the blender version define.
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/ray_linn/GCC-4.7.0-with-ada/mingw-w64-gcc-4.7.0-runtime-2.0.1-static-ada-20120330.7z/download
Other builds may also work but due to the constantly changing nature of the compiler this cannot be guaranteed. I often had to change compilers while building the libraries and this one is the one that did the job for most of them.
This first support is experimental and considered "advanced". To enable pass -DWITH_MINGW64 during cmake configuration. Also make sure to extract the compiler on C:/MinGW and that MinGW/bin is in your path. To build check out lib/mingw64.
Initially the support is lacking until I get every library compiled correctly. For now you should disable WITH_CYCLES(sorry, I know some people are dying to do benchmarks, but still a few libs to go), WITH_IMAGE_OPENEXR, WITH_OPENCOLLADA, WITH_LIBMV and WITH_CODEC_FFMPEG(links but hangs on startup).
Still the tools are working, the memory limit is increased and due to the experimental nature of the setup, full optimization with SSE2 is available, which makes the build quite fast. Also the compiler and especially, the linker are way faster than regular MinGW.
The wiki docs have also updated. Happy testing!
If we open file for write, we create a new file and close it. Therefore we have existing path for GetShortPathName.
Strangely zlib fails on gzclose if file descriptors are used.
Not all file formats/calls are supported yet. It will be expended.
Please from now on use BLI_fopen, BLI_* for file manipulations.
For non-windows systems BLI_fopen just calls fopen.
For Windows, the utf-8 string is translated to utf-16 string in order to call UTF version of the function.
- Crash was caused by recursively copying directory into itself, fixed
by switching from opendir() to scandir().
- Also do not try to unpack images which doesn't have name.
which resolves some possible issues with operating files with quotes and backslashes.
Also this might resolve (or at least help) resolving compilation error on GNU Hurd platform
which will help a lot maintaining Blender for Debian.
- spelling - turns out we had tessellation spelt wrong all over.
- use \directive for doxy (not @directive)
- remove BLI_sparsemap.h - was from bmesh merge IIRC but entire file commented and not used.
- Static variables can be initialized with constants only.
- Removed bunifont.ttf.c from datafiles -- it's not actually a
data file. Unicode font loading stuff is not in blenkernel/font.c
- Allocate as much memory for unzipped data as it's needed.
Default read chunk is 512Kb.
- Fixed regression (or just a typo) in setting utf locale.
- Default locale set to en_US:en works fine now.
- Commented put Nepali language in user preferences -- it's
not supported by current droid font and imo it's better to
have nice font for languages we actually have translation for
rather than allowing to choose more languages in user preferences.
Copy unifont..ttf.gz from source tree to target datafile path( now ONLY works with cmake );
Set the locale the same with system's setting;
If need unicode font, unzip and load unifont when init ui styles;
Apply gettext() to labels in space_info.py, who are the main menu items.
Each of these should have been commit one by one. As they work well according to my tests, so I just lazily send a long list.
- modifier code was using sizeof() without knowing the sizeof the array when clearing the modifier type array.
- use BLI_snprintf rather then sprintf where the size of the string is known.
- particle drawing code kept a reference to stack float values (not a problem at the moment but would crash if accessed later).
