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
While SCons building system was serving us really good for ages it's no longer
having much attention by the developers and started to become quite a difficult
task to maintain.
What's even worse -- there started to be quite serious divergence between SCons
and CMake which was only accumulating over the releases now. The fact that none
of the active developers are really using SCons and that our main studio is also
using CMake spotting bugs in the SCons builds became quite a difficult task and
we aren't always spotting them in time.
Meanwhile CMake became really mature building system which is available on every
platform we support and arguably it's also easier and more robust to use.
This commit includes:
- Removal of actual SCons building system
- Removal of SCons git submodule
- Removal of documentation which is stored in the sources and covers SCons
- Tweaks to the buildbot master to stop using SCons submodule
(this change requires deploying to the server)
- Tweaks to the install dependencies script to skip installing or mentioning
SCons building system
- Tweaks to various helper scripts to avoid mention of SCons folders/files
as well
Reviewers: mont29, dingto, dfelinto, lukastoenne, lukasstockner97, brecht, Severin, merwin, aligorith, psy-fi, campbellbarton, juicyfruit
Reviewed By: campbellbarton, juicyfruit
Differential Revision: https://developer.blender.org/D1680
- pass string size to BLI_timestr() to avoid possible buffer overrun.
- quiet warning for mingw.
- include guards for windows utf conversion funcs.
- fix for mistage in edge-angle-selection check.
- some style cleanup.
* The minimize() function, which solves a least-squares problem, is
only needed for sharp remesh mode, but was being calculated for
smooth and blocks modes as well. Disabling this calculation when
it's not needed gives a big performance boost.
Changed one of the intersection tests to use < rather than <=
The sharp and smooth modes look fine now for the special case that was
reported broken; blocks mode looks correct but "jumps" slightly from
one octree resolution to another, so may need additional corrections.
The changes mostly center around two new structures, InternalNode and
LeafNode. These provide an explicit representation of the Octree
nodes, which formerly were manipulated as opaque byte arrays.
A fair amount of commented out/unused code was also removed. This
includes the "CINDY" code, which may yet be useful, easy to bring back
if so.
There should be no difference in the output of the remesh modifier,
but memory usage may be slightly different. The flood fill bytes are
no longer optional; they will be allocated whether or not the 'remove
disconnect components' flag is set. The leaf node is probably not as
tightly packed due to alignment issues; this could be fixed with the
__attribute__((packed)) flag in gcc (probably there's an MSVC
equivalent), but not sure it's worth it. The internal nodes should
take up less space on 32-bit systems, allocating sizeof(pointer) now
rather than constant eight bytes.
These changes were made in persuit of bug #30158 (remesh crashes on
PowerPC). There's still a fair amount of bitwise stuff in the Octree,
so may still be endian issues and not yet sure if this fixes the bug,
but should be much easier to track down problems now.
