Re: [Simulavr-devel] Plan for make a first release of simulavr

[Joerg Wunsch]

As Klaus Rudolph wrote:

> I would like to have a complete set of tools in a "suite release".

This is hard to do, and making this a requirement would probably delay
the release forever.  It cannot be the responsibility of an individual
volunteer team (simulavr in this case) to take care for everything;
that's what would usually be expected from a "packager", like Eric
used to be for WinAVR.

For Linux, the closest you could get as a "packager" were Bingo600
with his build script on avrfreaks.net.

For FreeBSD, there's no real "packager", but I'm maintaining a set of
FreeBSD ports for many AVR-related tools.

I don't know of anyone taking responsibility for that job for Solaris,
and don't know about the packaging state for MacOS X.

> Actually I could not find a
> info which version of binutils run with which compiler and debugger and
> which revision number of simulavr.

Normally, the goal is to have them independently enough from each
other to collaboarate between different releases (up to a certain
degree, of course).  For example, Dmitry Xmelkov just committed a
change to avr-libc's testsuite yesterday to make it compatible with
GCC 3.3 - which implies that the actual library itself is still
compatible with that old compiler version (as only the testsuite was
apparently slightly broken in that respect).

> ..., gdb > 7.01 is not working with
> simulavr and other tools (jtag debugging) and so on.

As you know, I opened a bug report for that.  For the time being, you
could simply hardcode the patch for just AVR-GDB.  (Don't know whether
Bingo600 copied that hack into his buildscript, I did check it into
the FreeBSD repo.)

> Maybe it is not a good point to freeze for a release.

I don't know how the above would be related to releasing simulavr.  As
long as simulavr does at least its basic job (being a backend server
for GDB), and compiles with a sufficiently new compiler, it should be
fine to be released.

(Disclaimer: I've got no idea of the state of the tree, nor would I
claim to belong to the simulavr developers team in any way.  So take
me merely as an outside observer here.)

> >> Specially, the Python and TCL interface exposes all internals,
> >> therefore any change may break some script.

> > How many people are really using that already?  ...

> I use TCL a lot as setup for my regression test of my projects.

The question was about a possible impact to the users of changing the
Tcl API.  I could imagine that *you* are using it ;-), after all, it's
where you've once been starting with.  But I think you would be in a
position to adapt to smaller API changes upon the next release without
much problems.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)