removed 32-bit Appveyor builds and sped up cygwin build a bit#3143
Conversation
I do not understand this explanation to remove this. Because we don't have any coverage elsewhere it is better that appveyor gives us some coverage. I know that there is interest in a 32-bit release build also. If we can move the build to github actions then that would be interesting. |
The reasoning is that we basically only test this with the oldest and slowest compiler. I will added it to the GitHub actions soon. |
|
Turns out it's a bit tricky to get 32-bit to work - but it's in progress - see #3144. |
|
This can be merged - x86 build for GitHub action has been implemented in the other PR. |
|
ok when #3144 has been merged we can merge this also. |
Wo do not build for 32-bit in any of the other builds and Appveyor is our slowest (and mostly discarded because of that) build so it doesn't really make sense to do that. We should limit to a bare necessities build just to make sure it compiles and test for basic functionality since these are legacy compilers. It is quite unlikely some code will just be broken for a single configuration. We will move a few more things in upcoming PRs.
It might also make sense to not do release builds since we don't do that for most other platforms either but Visual Studio projects configurations for Debug/Release are completely separate and might be accidentally broken by incomplete changes so unfortunately we cannot really do that. I think having a single Release build on Visual Studio should be fine. So if we just do that for the latest available version we could just drop those for older ones.
Also the cygwin build was not using all threads for building the tests.