Re: [avr-gcc-list] Living With Atmel Studio 6.0

[David Brown]

On 09/08/12 19:05, David Kelly wrote:
> On Aug 9, 2012, at 11:18 AM, Erik Christiansen wrote:
>
> > > You should be highly sceptical about using integrated SVN clients
> > > in other programs.  It is important that you don't mix major
> > > version numbers of the svn clients on a machine - you'll end up
> > > corrupting your local svn metadata, or at least getting error
> > > messages about version compatibility.  So install TortoiseSVN gui
> > > client /and/ command line tools, and stick to integrated svn
> > > clients that work using external command-line tools.  (This is
> > > for brain-dead windows, of course - on Linux or BSD you install
> > > the subversion client libraries once, and all programs use that
> > > automatically.)
> >
> > Having observed other projects repeatedly have trouble with
> > M$-based version control applications, I've only allowed versioning
> > on unix. Things have doubtless improved more recently.

If the "M$-based version control" was Source Safe, then it is not 
surprising that people had trouble with it.  After all, MS themselves 
never used it, and they recommended users do a database rebuild at least 
once a week to stop the inevitable database corruption from spreading!

> I do host my SVN repository on MacOS X. I will not let other SVN
> executables directly manipulate my repository.

One of the reasons we standardised on SVN for version control is that it 
works well cross-platform.  We have people using it on Windows, Linux 
and Macs (no BSD, AFAIK).  Of course, the server is Linux.

> > > You should not have to exit AS6 to make it save files (or else it
> > > is worse than I thought).  As to which files to store in the svn
> > > repository, that is up to you.  I store the source files
> > > (obviously), Makefiles, and often the final .hex file (since it
> > > makes it convenient for testing or programming from different
> > > machines).
> >
> > Yes, and the specifications, in plaintext preferably. I've rarely
> > had them remain static for the life of a project. That makes it
> > easier to prove "Specification Redefinition" as cause of a reported
> > defect, for use in the bug database, as it comes into use prior to
> > alpha testing.
>
> That is a bone I have to pick with IDE's. I want things written out
> nice and simple as with Makefiles, not buried under a GUI.

You can use external makefiles with most IDE's.  It certainly works fine 
with Eclipse.

> I have a Windows project which uses libtomcrypt. Got the lib compiled
> long time ago under VS2008 Express. Then built another project
> linking against it. This past week I needed to start another and
> spent nearly a solid day hunting down the buried small changes in
> each project's Properties before I finally had a new project that
> would build.  :-(
>
> But also some here are mistaking the IDE with the text editor.
>
> I am happy with the gnu toolchain, build with Makefile. Edit with
> something else. But the one big thing Atmel needs to get right is the
> debugger.

Previously, I have used avr-gdb and avarice for debugging AVR's.  I 
haven't done so for a while (I haven't done much AVR work in the past 
few years, and the boards either haven't had JTAG, or I haven't needed 
to use it), so I don't know the current state of these tools.  Some time 
I must have a look at them again, and see if I can use Eclipse as a 
front end for the debugger (although I quite like command-line gdb - 
it's very fast and efficient to use).