On Sat, 11 Jun 2011 11:13, Stefan Seyfried
Am Tue, 7 Jun 2011 11:07:00 +0200 (CEST) schrieb Richard Guenther
: And no, GCC does not embed a spell checker.
Will it somewhen in the future?
I guess not, as the main goal of the g* tools (gcc, gdb, glibc...) seems to be "Make them deliberately hard to use". At least if you compare them to tools like the valgrind suite or clang and friends or eglibc, which seem to be developed with the goal of maximum usefulness, you could easily come to this conclusion...
This, well -forces- the question: Would a developer be better served if (s)he uses clang and/or eglibc in his/her dev environment and only afterward tests on gcc and/or glibc compatibility? --- As a dev I seek ease of use, clear and early error-detection, helpful status/warning/error messages and a documentation that can be read without having a degree in obscure languages first. --- As far as I can see the g* tool ( including autoconf ) either have left this path or where never on it. A friend reported latly of a problem in a program that he could only even find as he tried the intel-c-compiler instead of the gcc. gcc didn't even fail the compile. As debian and derivates has/have done the change, what would we win and/or loose, -beyond the time invested-, by a change from glibc to eglibc? Most of the work would be adapting the needed patches from debian for our use where upstream is still fixed on glibc. I see both sides, the dev and the packager. Both are *packed* with frustration, obscure messages from the tools and other hindrances. What will help us in the mid-term and in the long-term? Short-term is clear, but what beyond ? Yamaban, who is frustated by the state-as-it-is-and-was of the g* tools. PS: Sorry for the rant. Ignore it, if it gets you angry. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org