Talk:GSoC - Windows Support - Revision history

Ramack: /* sys/wait.h */ new section

2016-05-01T10:47:42Z

sys/wait.h: new section

← Older revision		Revision as of 12:47, 1 May 2016
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

Ramack at 17:30, 30 April 2016

2016-04-30T17:30:33Z

← Older revision		Revision as of 19:30, 30 April 2016
Line 8:		Line 8:
	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...		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...
	[[User:Ramack\|Ramack]] ([[User talk:Ramack\|talk]]) 19:28, 30 April 2016 (CEST)		[[User:Ramack\|Ramack]] ([[User talk: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...

Ramack at 17:28, 30 April 2016

2016-04-30T17:28:19Z

← Older revision		Revision as of 19:28, 30 April 2016
Line 4:		Line 4:

	What do you think?		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...
		+	[[User:Ramack\|Ramack]] ([[User talk:Ramack\|talk]]) 19:28, 30 April 2016 (CEST)

Hzwakenberg: Created page with "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 wa..."

2016-04-30T08:30:04Z

Created page with "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 wa..."

New page

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?