The Issue
=======
For a long time now MinGW has been unsupported and unmaintained and at this point,
it looks like something that we should just leave behind and move on.
Why Remove
==========
One of the big motivations for MinGW back in the day is that it was free compared to MSVC which was licensed based.
However, now that this is no longer true we have basically stopped updating the need CMake files.
Along with the CMake files, there are several patches to the extern libs needed to make this work. For example, see:
https://developer.blender.org/diffusion/B/browse/master/extern/carve/patches/mingw_w64.patch
If we wanted to keep MinGW then we would need to make more custom patches to the external libs and
this is not something our platform maintainers are willing to do.
For example, here is the patches needed to build python: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3
Fixes T51301
Differential Revision: https://developer.blender.org/D2648
* Fix BLI_file_touch, used to add one dummy byte ((unsigned char)EOF) to empty files!
* Get rid of static global temp string in WIN32 area (very bad, and useless!).
* Get rid of paranoid NULL checks in WIN32's BLI_gzopen().
* Add non-relative filename asserts to WIN32 file operations too.
* ifdef-out BLI_move and BLI_create_symlink, unused (and the later is not even implemented for windows).
Partly based on patch and points raised by Jason Wilkins (jwilkins) in T32870, thanks!
Missed adding return value in one place.
Thanks a lot to Thomas Szepe for reporting the issue and finding the solution!
Question remains: how could MSVC allow such a code to compile in some cases
(own win64 + scons buildbot win32 were OK with that it seems!).
Crappy compiler, not comming to the rescue of stupid dev...
There was two different issues here actually:
* Own (very high) stupidity only gave 8 chars to file name (sic).
* list dir returns dirpaths without a trailing slahs, but expects them to have it it seems. :|
Don't know when this sneaked in, I did wrote that part of the patch on win VM with MSVC2013... :/
Note: letting asside warnings for now, then should not prevent building anyway.
Current temporary data of Blender suffers one major issue - default 'temp' dir on Windows is never
automatically cleaned up, and can end being quite big when used by Blender, especially when we have
to store per-process data (using getpid() in file names).
To address this, this patch:
* Divides tempdir paths in two, one for 'base' temp dir (the same as previous unique tempdir path),
the other is a mkdtemp-generated sub-dir, specific to each Blender instance.
* Only uses base tempdir when we need some shallow persistance accross Blender sessions - and we always
reuse the same filename (quit.blend...) or generate small file (crash reports...).
* Uses temp sub-dir for heavy files like pointcache or renderEXRs (Save Buffer option).
* Erases temp sub-dir on quit or crash.
To get this working it also adds a working 'recursive delete' to BLI_delete() under Windows.
Note that, as in current code, the 'recover render result' hack-feature that was possible
with SaveBuffer option is still removed. A real renderresult cache feature will be added
soon, though.
Reviewers: campbellbarton, brecht, sergey
Reviewed By: campbellbarton, sergey
CC: sergey
Differential Revision: https://developer.blender.org/D531
compressed files we were not passing the full wide char path to zlib, so not
all file names worked. Now we use gzopen_w available in new zlib versions.
Patch by Tamito Kajiyama, I added an extra check for the zlib version so it
keeps compiling with older versions for now.
For platform maintainers:
Part of this commit are zlib 1.2.8 libraries for windows 32 bit. We still
need update libraries for windows 64 bit and mingw. There's a readme.txt
and build.bat included with instructions on how to build.
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.
