|
I agree that perhaps a FAQ is necessary. Interestingly though, the
questions discussed below are in multiple domains; not only AVR GCC and
Unix newbie, but C language and embedded programming.
For example, as you mentioned, the typical question about a missing
'volatile' is more of a C language issue or an embedded programming issue.
When learning C, one is supposed to learn what the 'volatile' keyword is
for and how and when it gets used, such as in optimized sections or in an
interrupt service routine. Granted, that one generally only gets exposed
to writing ISRs when programming for embedded systems.
The problem that started this thread has more to do with the ability
to interpret linker error messages. I ran into the same problem myself
with a different math function. I called the function, included the right
header file, knew that I was linking in the "standard C library", and
voila: I got a linker error saying it can't find the function. "So perhaps
they're in a different library?" I thought. Sure enough, libm.a looks like
it might be a math library, I link it in and it works. Now it becomes a
Unix newbie programming issue: I've done all my embedded programming work
the last 7 years on a Windoze platform. I had no idea that the "standard C
library" was in 2 files. Much less, I'm not used to a library being called
an "archive" and having a .a file extension, I'm used to a library with a
.lib extension. An archive in my mind is a backup.
Now, I don't want to give the impression that I'm complaining. After
all, I know that GCC comes from a Unix background. I expect differences,
quirks even. I've been doing as much digging for information about it as I
can from whatever source I can and it's all worked for me. I haven't even
had to resort to asking the list for help and my 15,000 line+ project has
been coming along fine and I think the AVR-GCC compiler is great!
What I did like about AVR Freaks was their creating the Windoze
binaries and packaging in an installation. That's nice if you're new to
GCC. There's a learning curve with any compiler; much more if you have to
build it from the source yourself. I'll admit that I'm more interested in
using the compiler than having to build it.
I agree that the AVR Freaks makefiles are overly complicated, but for
a different reason. I don't like there are 2 makefiles and that AVR Freaks
is unnecessarily hiding the main functionality. IMO, make and
makefiles aren't so complicated in what they do that it requires
insulating the user, which is a programmer, who should be used to
dealing with a certain level of complexity anyway.
As a side note, I would put forth the argument that any program
should not make a distinction between TABS and SPACES. They are both
non-printable characters and in most editors (at least on Windoze) it
requires an effort to tell them apart. There are always other means to
achieve the desired functionality.
After talking with Sander Pool off-line, I understand the reason
for seperate libraries: Unix history. But...is it still justified in
having that seperation? What is the down side in combining them? The down
side in leaving them seperated is more questions like the one that started
this thread.
So perhaps a general AVR GCC FAQ is needed.
Thanks,
Eric
-------Original Message-------
From: Joerg Wunsch
Date: Friday, July 26,
2002 04:19:37 AM
To: address@hidden
Subject: Re:
[avr-gcc-list] strange behaviour with ceil() > When migrating to AVR GCC from another compiler (like I have > recently), how / where is one supposed to find out that the > standard C math routines are in a seperate library file? That's a FAQ (not only for AVR-GCC but for Unix newbie programmers as well), the same like the typical question about a missing `volatile' variable declaration. So basically, we probably need a FAQ that is referenced from all locations where one could obtain AVR-GCC from. OK, the requirement for having a libm.a separate from libc.a is rather a Unix historical artifact, and one could argue that both could easily be incorporated into a single libc.a as well... > I applaud AVR Freaks for trying to make the compiler easy to install > and use (it worked for me at any rate), but a little more > documentation would help. To be honest, i always found the AVR Freaks Makefile templates overly complicated. In some respects, it's even dangerous in that it encourages people to employ a bad Makefile style that is at the risk of becoming buggy, like with their variable name indentation to right-align them at the equal sign: you /must/ use spaces to indent them, if you use a TAB, Makefile syntax mandates that a TAB is introducing a shell command, and some implementations will simply complain about it. So it would be better to simply start all variable names flush left. My typical AVR project Makefile doesn't have more than 50 lines, where i copy about half of it as a `template' from another old project, and modify the remainder for the actual filenames in my new project. But then, i come from a Unix background, so compiler flags and arguments as well as the use of `make' is quite common to me. However, the risk of those large template buildings is that you never really learn how `make' is working, and are at the end of your road as soon as you encounter a situation which is not covered by the template. So i'd rather encourage people to not only study the compiler documentation, but that of `make' as well. (Of course, i have no clue whether the texinfo documentation of gcc and make is actually included and easily readable in the Windows distributions.) -- J"org Wunsch Unix support engineer address@hidden http://www.interface-systems.de/~j/ avr-gcc-list at http://avr1.org . |
|||
|
|
IncrediMail -
Email has finally evolved - Click
Here