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. ;-) _______________________________________________ Simulavr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/simulavr-devel
