Svein E. Seldal wrote:
Steve Underwood wrote:
Hi,
Some documentation would be *very* good. That is why we have a
manual. What it says in the manual is still the current recommended
way to build. GCC 3.3.x doesn't really have any advantages. 3.4.x
still seems to have issues. I think GCC 3.2.3 is still the most
workable version. That is the one the documentation describes how to
build. The documentation should be updated in relation to binutils,
since you need the patch binutils to get support for some of the
newer devices. Also, I really should put the latest gdbproxy on the
sourceforge site, where the documentation says you should look. Apart
from that, I think the documentation is still OK.
We do get a number of people complaining they have given up trying to
build the tools, while they admit to never having looked at the
manual. :-) Also, far too many people are *trying* to build the
software. Lots of them are using windows. The windows installers are
a much better choice for them, in most cases.
Well I'm one of those which are experienced (Linux) GCC users. I have
been using gcc for other embedded targets a lot. I have never been
using so much time to figure out how to get a toolchain up and running
before, that I had with this one. One of the biggest timeconsumers was
to grep through all the docs and finding only that halfpage of usable
info that is required for building this stuff.
When I read the manual, it doesnt tell you very much (chapter 1.2 and
11.1-11.2). And quite francly, since a 3.3.x and 3.4.x version is
available, I guessed that the docs is obsolete and a newer
reccommendation is available.
It tells you what you need to collect, and the commands you need to use.
What else would you want.
IMHO a little note that the newer versions aren't stable/working would
be good. In that manner you'd inform the users that this doc is still
updated and they would trust the source saying that gcc 3.2.3 is still
in the game.
Fair point, but I am not sure how to deal with it. The manual hasn't
changed for some time because it hasn't needed to change. However, that
makes it look like it isn't being maintained. Should I just bump the
update date every few weeks to make it look fresh? :-)
And the naming clobber with the CVS gcc version is confusing at best.
I had to do 5 gcc recompilations before I found a working official gcc
+ msp430 gcc patch combination. So yes: documentation is very
important at this stage, but its not quite there yet.
There is a not in the CVS directories to say which GCC they do with, but
that isn't really a solution. Renaming things in CVS is very
troublesome, so once the names slipped out of step they stayed like
that. If Dimitry can get MSP430 support merged into CVS at RedHat, maybe
the versions in our CVS will not matter much for too long. :-)
But, its very little which needs be done to lower the introduction gap:
o Write a readme file in the gcc CVS directories with the build
procedure and a note about its stability
o Put up a simple build info web page (in addition to the chapter
in the doc) - user find it easier to find in a webpage, than into a
manual.
o Update the docs saying that gcc-3.4.x and gcc-3.3.x is unstable.
I think the building procedure would just be repeating the manual. If
people can't be bothered reading the manual I have no time (and
considerable abuse) for them. A clearer note in each directory about its
status sounds worthwhile.
Regards,
Steve
