FW: [avr-gcc-list] Stable & development releases, couple of other things

[J.C. Wren]

Ted wrote this reply, and asked me to post it to the list as he's having
trouble at the moment.

        --John

On Sat, 19 Oct 2002, J.C. Wren wrote:

:)      I'm back to trying to build both a stable and a development GCC AVR
:)package.  My question is this:  What are the cvs pull options for pulling
a
:)version that would be considered stable (binutils, gcc, and avr-libc)?
:)These are typically denoted by a -rxxx option, where xxx might
binutils-2_13
:)binutils (yielding "cvs -z 9 -d
:pserver:address@hidden:/cvs/src
:)co -rbinutils-2_13 binutils").

To find all the cvs tags in a project, pick a file and do this:

  $ cvs status -v COPYING

>From that you can pick the tag to use with the -rXXX option when doing a
checkout.

:)
:)      I believe I have the parameters correct for pulling the latest
:)development version.

No -r option is needed when pulling the head of the tree since that's the
default action.

:)
:)      It would be nice if the avr1.org page had a good link to Savannah.  I'm
:)sure it's all pretty intuitive when you've been working with it for a
while,
:)but I tend to hop back and forth between projects, and sometimes forget
:)where websites are.  Now sure, I could bookmark them all (and I do), but
the
:)new person coming along who subscribes to the list has to be having a
bitch
:)of a time figuring out where the current docs and etc are.  And seeing as
:)www.avr1.org is listed at the bottom of each and every mail message,
that's
:)a good logical place for someone to start.  I also remember seeing a
message
:)from Ted that he's started a new website, but damned if I remember what it

www.openavr.org (or .net or .com)

:)is.  So please Please PLEASE put some links on avr1.org.  (As a side note,
:)seeing how out of date a couple of the pages are, perhaps they should just
:)be deleted.  One of the WORST problems Linux suffers from is people and
:)search engines mirroring 8 year old out of date information.)

Agreed.

:)
:)      Lastly, two related items.  What's the appropriate method for submitting
a
:)patch?  I notice that eeprom_block_read exists, but eeprom_block-write
does
:)not.  This is easy to write, but just this moment, it'd be easier to beg a
:)maintainer to add it (since it's basically cut'n'paste), since I don't
have
:)the procedure for submitting a patch to the maintainers.  Straight diff?
:)patch format?  Any particular parameters?

If you have a cvs sandbox, the easiest thing to do is make your changes and:

  $ cvs diff -u > mypatch.diff

This method will not pick up any new files you have created though, so you
then have to do something like this:

  $ for f in $newfiles; do diff -u /dev/null $f >> mypatch.diff; done

just make sure all the files in $newfiles use the same path as the cvs diff
part.

You should make sure your patch applies cleanly too since that makes the
maintainers job easier. The easiest way to check a patch is the try to use
it to undo itself as such:

  $ patch -p0 -R --dry-run < mypatch.diff

You may need to change the -p0 option a bit though. The --dry-run option
should be obvious.

There's no difference between a diff and a patch format, they are both just
generated using the diff command.

I prefer the -u option as it makes things easier to read and a tad smaller
than -c. In all cases you should use a context diff (-u or -c3).

Hope that helps.

Ted Roth



avr-gcc-list at http://avr1.org