appveyor tests: miss creation of non-wide non-utf8
Opened this issue · 2 comments
Note: I haven't checked if this is part of the cmake definitions used (so just needs to be added to appveyor.yml) or are missing there, too.
Note: we may miss a MinGW GCC build in the cmake definitions and/or its use in appveyor.yml, too.
We do compile the OS/2 and DOS ports with 8-bit characters, so I don't think we've really left this completely unchecked. Theoretically speaking, at least, we could have compiles with
(1) 8-bit characters, (2) wide chars, (3) forced UTF8;
(1) 32-bit chtypes vs. (2) 64-bit chtypes
(1) DEBUG vs. (2) non-DEBUG
(1) DLL vs. static
Most platform support at least two different compilers (gcc and MSVC, or gcc and clang, or Digital Mars and Borland and Watcom 1.9 and Watcom 2.0)
...and that's for DOS, DOSVGA, fb, the DRM variant of fb, OS/2, Plan 9, SDL1 and 2, VT (DOS, Windows, and Linux), WinCon, WinGUI, and X11. Which would be roughly 3x2x2x2x2x14 = 672 possible compilation tests. (Kinda thought it might turn out to be more than that.)
I do think we should have at least a few tests of, for example, 32-bit chtypes (I don't think we have any right now), and there may be other variants that would be good stress tests. I'd hesitate to test everything, though.
I do think we should have at least a few tests of, for example, 32-bit
chtypes (I don't think we have any right now), and there may be other variants that would be good stress tests. I'd hesitate to test everything, though.
Given that huge number I totally agree.
If possible I'd suggest to add the following for Windows, both to have tests and to have usable artifacts:
- MinGW 32bit with 32bit chtype, non-wide
- MinGW 32bit with 64bit chtype, non-wide
- MinGW 32bit with 32bit chtype, utf8
- MinGW 32bit with 64bit chtype, utf8