From: Borut R. <bor...@gm...> - 2012-01-22 16:51:13
|
On 22. 01. 2012 13:00, Philipp Klaus Krause wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear sdcc developers, > > sdcc 3.1.0 has been released a while ago, and we've received some bug > reports about bad bugs (wrong code being generated silently) since; > some of them seem to be regressions. I've been adding them to > https://sourceforge.net/apps/trac/sdcc/wiki/SDCC%203.2.0%20Release > (except for those that have been fixed quickly), where they now sit > alongside the postponed stuff from 3.1.0. The gbz80 port has made some > progress, and code size and number of regression test failures are > down a lot compared to 3.1.0. > On the other hand I intend to work on some bigger things in spring and > summer (stack allocation, coalescing and making the new register > allocator work for another port, most likely the hc08 or hcs08), which > is likely to break things. I assume that you'll make new branch(es) for the new stuff, so the 3.2.0 release can be done from the svn head? > Thus, a 3.2.0 release in march, maybe with the first rc being made in > late february seems like a good idea to me, if we can fix some of the > bugs mentioned above until then: Our users get a release that has the > features of 3.1.0, but less bugs, and the best gbz80 port we've had so > far. AFAIK, we've had no major changes since 3.1.0 that are likely to > break existing things. And the upcoming major changes won't be merged > (and most likely not even be complete) before 3.2.0. I agree. But don't forget to update the documentation and SDCC 3.2.0 Feature List. I have an impression that some recently added functionalities are not documented yet, for example ucsim support for gbz80... I have a working version of sdar utility derived from gnu binutils ar. Actually I wrote the bfd interface to asxxxx .rel format, only the part needed by ar. I noticed some doubts if this is really necessary, so I'm asking for your opinion whether to include it or not. On Oct 15, 2011 Philipp wrote: > For the future (probably after the sdcc 3.1.0 release) I plan to > implement a librarian ("sdar" or "sdlib"), since sdcc is currently using > the "system ar" librarian. Why? What's the problem with using "system ar"? On Oct 15, 2011 I responded: There are few reasons: - to have a full "self containing / supporting" sdcc tool-chain. - not all *nix default installations include development tools, so the "system ar" might be missing - there is no "system ar" utility on Windows platforms, so users have to take one from mingw or cygwin packages Borut |