Difference between revisions of "Talk:GSoC - Windows Support"
(→sys/wait.h: new section) |
|||
| Line 14: | Line 14: | ||
---- |
---- |
||
For the installer, I'd support the choice of NSIS, but if there are further (free) options it would be interesting to see some comparison - this is also the reason why I tried to prevent the usage of NSIS in the original idea: I did not want to limit the students choice... |
For the installer, I'd support the choice of NSIS, but if there are further (free) options it would be interesting to see some comparison - this is also the reason why I tried to prevent the usage of NSIS in the original idea: I did not want to limit the students choice... |
||
| + | |||
| + | == sys/wait.h == |
||
| + | |||
| + | actually I think it is about "convincing" the compiler that it is NOT running on a POSIX system... Or maybe we "just" need to fix the #ifdefs, anyhow, on windows we need to include windows.h and NOT wait.h |
||
Latest revision as of 11:47, 1 May 2016
Have we really settled on Minwg64/GCC as a compiler? The other day I followed a discussion (non-Eiffel related) about the relative merit of GCC vs. CLANG/LLVM. The tenure was that CLANG is much better at doing static code analysis to catch errors. Optimisations were slightly better too, but this I personally find less significant. If a CLANG compile pass would show us that the Liberty C-code generator can be improved, that would be a valuable asset. Example from the past: my experiments with Pelles-C, which showed that "C code for local variables are still generated, even though all accesses to them are removed", see https://savannah.gnu.org/bugs/?42991 This Windows-port project could possibly improve the base product. Then again, CLANG (and other static verification tools) could be used already on Linux as is, so strictly speaking, we wouldn't really need the Windows-port project for that.
What do you think?
I think the choice of MinGW64 is good, as it fits best to the GNU compiler for Eiffel to work together with other GNU compilers. But the point on CLANG is still feasible, but we can do this also on linux (and probably much easier, because it is more direct). To really improve the generated C code I think we have much potential even with GCC on linux - for example we could enable all warnings first. And next I think we should go for some static code checkers (e. g. pclint) and as next step I'd like to see some usage of frama-c - I am sure this goes way beyond CLANG... Ramack (talk) 19:28, 30 April 2016 (CEST)
For the installer, I'd support the choice of NSIS, but if there are further (free) options it would be interesting to see some comparison - this is also the reason why I tried to prevent the usage of NSIS in the original idea: I did not want to limit the students choice...
sys/wait.h
actually I think it is about "convincing" the compiler that it is NOT running on a POSIX system... Or maybe we "just" need to fix the #ifdefs, anyhow, on windows we need to include windows.h and NOT wait.h