[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: J.C. Wren
Subject: FW: [avr-gcc-list] Stable & development releases, couple of other things
Date: Sat, 19 Oct 2002 12:29:16 -0400

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


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
:)version that would be considered stable (binutils, gcc, and avr-libc)?
:)These are typically denoted by a -rxxx option, where xxx might
:)binutils (yielding "cvs -z 9 -d
:)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

:)      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
:)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
:)new person coming along who subscribes to the list has to be having a
:)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,
:)a good logical place for someone to start.  I also remember seeing a
:)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.)


:)      Lastly, two related items.  What's the appropriate method for submitting
:)patch?  I notice that eeprom_block_read exists, but eeprom_block-write
:)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
:)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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]