From: Bernhard H. <ber...@be...> - 2004-01-04 23:13:17
|
What do you think about a release? The last release is from 2001-09-29! IMHO the current sdcc is the best we ever had. And it's certainly better than 2.3.0. Do you have anything on your disk, which must be in the next release? Bernhard |
From: Vangelis R. <vr...@ot...> - 2004-01-05 02:18:49
|
On Sun, 4 Jan 2004, Bernhard Held wrote: > What do you think about a release? The last release is from 2001-09-29! IMHO > the current sdcc is the best we ever had. And it's certainly better than > 2.3.0. > > Do you have anything on your disk, which must be in the next release? That's great. I do not know about the 2.3.0 (since I am new in SDCC) but definetely 2001 is ancient history!... :-) I have many things for the pic16 port. Among others: * stack/frame pointer support for function parameters * 99% complete relocatable objects The problem is that I cannot commit the changes right now. The main reason is that older sources will not compile correctly and people will have problems with it. As far as I can understand not many people use SDCC for 18F devices so there will be no much trouble. In any case changes (not many of course) will have to be done to original sources. Shall I proceed? Is anyone using the pic16 port seriously and needs special attention? ANW, are you going to set a deadline for committing changes? I also have a comment about something I noticed recently, when you changed the .version file to 2.3.7. Each time the version is changed, one must run ./configure [blah blah blah] for the changes to take effect (so SDCC will prompt the correct version number). Are there any plans, so that the version number can be retrieved during compilation, without needing to reconfigure the whole package? Regards, Vangelis |
From: Bernhard H. <ber...@be...> - 2004-01-05 22:42:14
|
Thanks for all your replies! > The problem is that I cannot commit the changes right now. The main reason > is that older sources will not compile correctly and people will have > problems with it. > As far as I can understand not many people use SDCC for 18F devices so > there will be no much trouble. The pic port has still the status "in development", so I would not hesitate to commit the changes. And: the version of sdcc is not a "holy cow": please increase the version every time you commit a major change. Then it's easy to tell the people, that from version x.y.z on things have changed. It helps a lot to sort out bug reports. > Shall I proceed? Yes ;-) > ANW, are you going to set a deadline for committing changes? Not yet. I will wait, until the bigger changes have proofed to be stable. After this I will increase the version number to 2.4.0 (yes! why not?) and tag the CVS. > I also have a comment about something I noticed recently, when you changed > the .version file to 2.3.7. Each time the version is changed, one must run > ./configure [blah blah blah] for the changes to take effect (so SDCC will > prompt the correct version number). Are there any plans, so that the > version number can be retrieved during compilation, without needing to > reconfigure the whole package? There are no plans. IMHO this is not a big problem. E.g. my latest sdcc still reports 2.3.6 ;-) And running 'configure' isn't a big problem too (at least on linux). If you prefer a quick+dirty solution: edit sdcconf.h, line 9...12. Bernhard |
From: Maarten B. <sou...@ds...> - 2004-01-08 08:54:14
|
> > ANW, are you going to set a deadline for committing changes? > Not yet. I will wait, until the bigger changes have proofed to be > stable. After this I will increase the version number to 2.4.0 (yes! > why not?) and tag the CVS. Allthough I'm not among the developers, I do have an opinion about this. I think it's great you're going for a new release. And it should be 2.4.0. May I suggest also branching the project immediately after that to version 2.5.0 for new developments and keep 2.4.x open for bug fixes only, so no new features. This is very common practise in open source development. What should be in it? Well, how about everything that's in now and nothing more? But I recommend also looking into the (rather long) list of reported bugs. Stop implementing RFE's for a moment and focus on the bugs for a while. I think this can create a very good and stable version. Finally something about pragma's. I agree it's a mess and should be fixed. But only if most of them were introduced after the last official release, otherwise this is an RFE and nothing like a bug. Greets, Maarten Brock |
From: Bernhard H. <ber...@be...> - 2004-01-08 12:48:34
|
> I think it's great you're going for a new release. And it should be 2.4.0. > May I suggest also branching the project immediately after that to > version 2.5.0 for new developments and keep 2.4.x open for bug fixes > only, so no new features. Branching, merging and comitting to different branches in cvs is no fun. And I don't have time to maintain two branches, porting fixes back and forth. I'm sure this applies to the other developers as well. Nearly always with very rare exceptions the latest version in cvs was the best and most stable. Therefore the next release will be simply a "special snapshot", just for people who need official releases. > This is very common practise in open source development. It's common in popular projects with sufficient man power. > Stop implementing RFE's for a moment and focus on > the bugs for a while. I think this can create a very good and stable > version. Great idea :-> If you manage the next release of SDCC, I'll fix one or two bugs from the tracker ;-) Bernhard |
From: Michael H. <mic...@ju...> - 2004-01-09 09:08:02
|
I'll handle the release, if no one else wants to. The last one was a branch tag that was very short lived. The basic steps were: * Mad dash for any last features * Announce a code freeze one week before * Fix bugs * After the week has passed, make sure the build is clean and the regression tests all pass * Make the sdcc-2_4_0 tag/branch * Build off that, making any final changes in that branch. * Bless the release. If anyone does want a 'known good' branch, they can use 2.4.0 later. However the sdcc release schedule is slow so as Bernhard says the latest is normally the greatest. One idea is quarterly releases, just to provide an 'official' release at a regular time. -- Michael On Friday, January 9, 2004, at 01:48 AM, Bernhard Held wrote: >> I think it's great you're going for a new release. And it should be >> 2.4.0. >> May I suggest also branching the project immediately after that to >> version 2.5.0 for new developments and keep 2.4.x open for bug fixes >> only, so no new features. > Branching, merging and comitting to different branches in cvs is no > fun. And > I don't have time to maintain two branches, porting fixes back and > forth. > I'm sure this applies to the other developers as well. > Nearly always with very rare exceptions the latest version in cvs was > the > best and most stable. Therefore the next release will be simply a > "special > snapshot", just for people who need official releases. > >> This is very common practise in open source development. > It's common in popular projects with sufficient man power. > >> Stop implementing RFE's for a moment and focus on >> the bugs for a while. I think this can create a very good and stable >> version. > Great idea :-> If you manage the next release of SDCC, I'll fix one or > two > bugs from the tracker ;-) > > Bernhard > > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > sdcc-devel mailing list > sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-devel > |
From: Bernhard H. <ber...@be...> - 2004-01-11 19:51:44
|
Hi Michael, I'm sorry about the late reply, but yesterday I had a conflict with a carpenter's plane. My left thumb is 2...3 mm (~0.1 inch) shorter now. I didn't feel like typing on a keyboard... > I'll handle the release, if no one else wants to. The last one was a > branch tag that was very short lived. The basic steps were: I would be more than happy, if you could do the job! I've created an account 'sdcc-builder' at the CF, which runs the nightly builds. The mingw compiler is available there. The home directory is world-readable. Moreover I share the password with all interested SDCC developers. If you've a question about this account, the nightly build, the CF or anything else, please feel free and ask me. > One idea is quarterly releases, just to provide an 'official' release > at a regular time. Yepp, after becoming familiar with the release procedure, I planned to make releases more often too. Bernhard |
From: Borut R. <bor...@si...> - 2004-01-10 20:28:43
|
Maarten Brock wrote: > Finally something about pragma's. I agree it's a mess and should be > fixed. But only if most of them were introduced after the last official > release, otherwise this is an RFE and nothing like a bug. I'm afraid that not many pragmas were introduced after the last official release. And I didn't say they I'm talking about a bug (even if we can call it a design bug). I (actually Frieder Ferlemann) just wanted to point to the area, which is messy and can be improved without a lot of effort. So, you are right, this is definitely a RFE. The question is, whether to do changes before the official release, and how to do it. I propose to do it before the release, so we will have cleaner situation in the future. The answer on "how to do it" is more problematic. Bernhard wrote: "In order not to make the mess even worse, I vote for a real clean up without backward compatibility!" My opinion is more conservative: - Retain backward compatibility in parallel with the new functionality - The documentation should be updated accordingly: only lower case pragmas, no "-" or "=". All other variants are deprecated an will be obsolete in the future. SDCC developers, I'm inviting you to express your opinion. If nobody else will join the discussion, I'll implement the Bernhard's proposal. P.S.: this discussion should probably be redirected to sdcc-user list, to hear their opinion... Borut |
From: Erik P. <epe...@iv...> - 2004-01-10 21:13:04
|
On Sat, 10 Jan 2004, Borut Razem wrote: > The question is, whether to do changes before the official release, and how > to do it. > > I propose to do it before the release, so we will have cleaner situation in > the future. > > The answer on "how to do it" is more problematic. > > Bernhard wrote: > "In order not to make the mess even worse, I vote for a real clean up > without > backward compatibility!" > > My opinion is more conservative: > - Retain backward compatibility in parallel with the new functionality > - The documentation should be updated accordingly: only lower case pragmas, > no "-" or "=". All other variants are deprecated an will be obsolete in > the future. > > SDCC developers, I'm inviting you to express your opinion. > > If nobody else will join the discussion, I'll implement the Bernhard's > proposal. My preference would be to backwards compatible. Also, if it's not unduely difficult, generate a warning when a deprecated form is used. This way it will be less of a surprise when it is finally obsoleted. Erik |
From: Vangelis R. <vr...@ot...> - 2004-01-10 22:30:10
|
----- Original Message ----- From: "Borut Razem" <bor...@si...> To: <sdc...@li...> Subject: RE: [sdcc-devel] Release > SDCC developers, I'm inviting you to express your opinion. > > If nobody else will join the discussion, I'll implement the Bernhard's > proposal. Quoting Erik's answer: >>My preference would be to backwards compatible. Also, if it's not unduely >>difficult, generate a warning when a deprecated form is used. This way it >>will be less of a surprise when it is finally obsoleted. I was thinking just that, when I saw Erik's message. Old forms should be gradually obsoleted. So let's give them some time (let's say 6 months, or so) for older programs to conform. A warning until they are completely obsoleted would be wonderful. But care should be taken by the port developers to support both forms of pragmas. Regards, Vangelis |
From: Borut R. <bor...@si...> - 2004-01-12 13:13:52
|
> SDCC developers, I'm inviting you to express your opinion. > > If nobody else will join the discussion, I'll implement the Bernhard's > proposal. The current score is 3:1 to retain backward compatibility (Borut, Erik, Vangelis : Bernhard), so I did it that way. I also updated the sdccman.lyx, and found out, that some pragmas are not documented: - sdcpp preprocessor pragmas: "standard" gcc cpp pragmas (documentation should be taken from gcc docs): poison once GCC poison GCC system_header GCC dependency SDCC specific sdcpp pragmas: sdcc_hash - implemented by Kevin - sdcc compiler front-end pragmas, valid for all targets: noinvariant - it is mentioned in chapter 3.2.8 Optimization Options, but missing in chapter 3.18 Pragmas induction stackauto overlay - sdcc compiler target (code generator) pragmas pic: memmap maxram pic16: maxram stack z80: bank= Any volunteer to update the documentation? Maybe Frieder? I didn't modify z80 pragmas portmode= and bank=, so the '=' is still required. Borut |
From: Erik P. <epe...@iv...> - 2004-01-05 06:31:10
|
On Sun, 4 Jan 2004, Bernhard Held wrote: > What do you think about a release? The last release is from 2001-09-29! IMHO > the current sdcc is the best we ever had. And it's certainly better than > 2.3.0. > > Do you have anything on your disk, which must be in the next release? I'm certainly in favor of a newer official release. We will never make it if we are waiting for all the ports to be completed and all the bugs to be fixed. Definately better than 2.3.0; I no longer feel that I should always doublecheck the .asm file to make sure the translation is correct (at least when compiling for 8051; the hc08 is another story). My only suggestion is to document the state of development of the various ports. Perhaps something like: Mature, on-going maintanance: mcs51, ds390, z80 Preliminary, in development: pic14, pic16, hc08 No longer maintained: avr, gbz80 Erik |
From: Michael H. <mic...@ju...> - 2004-01-17 03:55:20
|
Morning. I've setup a Wiki with a release plan at: http://sdcc.sourceforge.net/cgi-bin/release-wiki.pl There are instructions at the top on how to create an account to edit the page. Basically if you set your password to the editor password, 'crush', you can fiddle with the pages to your hearts content. This is a simple security measure to stop any vandals from coming through. Comments? Next step is to figure out what changes have to be made before starting the bug hunt. -- Michael |
From: Michael H. <mic...@ju...> - 2004-02-10 08:06:22
|
Well. That took some time. SDCC now compiles and tests cleanly on Gentoo 1.4 and Mac OS X 10.2.8-gcc3.3. The next step is to decide on anything that has to be in SDCC 2.4, and then to do a bit of a bug hunt. So. Are there any must haves? I'll wait a week, and if I don't hear anything I'll do the release. -- Michael On Saturday, January 17, 2004, at 04:54 PM, Michael Hope wrote: > Morning. I've setup a Wiki with a release plan at: > > http://sdcc.sourceforge.net/cgi-bin/release-wiki.pl > > There are instructions at the top on how to create an account to edit > the page. Basically if you set your password to the editor password, > 'crush', you can fiddle with the pages to your hearts content. This > is a simple security measure to stop any vandals from coming through. > > Comments? Next step is to figure out what changes have to be made > before starting the bug hunt. > > -- Michael > <PGP.sig> |
From: Bernhard H. <ber...@be...> - 2004-02-16 12:59:06
|
> There are instructions at the top on how to create an account to edit > the page. I tried to create an account, but it's not working. The main page is already very slow, may be the connection simply times out during registration :-( What I wanted to add is that I plan to build rpms for SuSE 8.2/9.0 and redhat 9.0. But these packages have low priority, I would add them anytime in the week after the release. > I'll wait a week, and if I don't hear anything I'll do the release. The week is nearly over, do you have already fixed a date? Bernhard |
From: Borut R. <bor...@si...> - 2004-01-05 20:42:37
|
> What do you think about a release? The last release is from 2001-09-29! IMHO > the current sdcc is the best we ever had. And it's certainly better than > 2.3.0. > > Do you have anything on your disk, which must be in the next release? I join the opinion of other developers: it is time to do it. I actually have two things in mind, which have to be done before the release: - Setup on WIN32 should add the sddc bin path to the PATH env. variable - I introduced the #pragma preproc_asm, which defines, if _asm blocks are preprocessed or not. This was done by fixing #828015. In the first version, the default was off, but then we found out, that there are files in SDCC library sources, which have #defines and #ifdef-ed code in _asm blocks. So I changed the default to on. And that is the current situation. Now there several possibilities: - to leave it as it is - to set the default to off and remove preprocessed code from SDCC library sources: #defines can be replaced by asm EQUs, #ifdefs can be solved by splitting big _asm blocks to smaller ones, so that #ifdefs will be outside the _asm blocks. If we decide to do it: is there a volunteer to change library sources? - to set the default to off and include #pragma preproc_asm on in library sources with preprocessor directives in _asm bocks. The SDCC documentation should be updated (#pragma preproc_asm documented), according to the decision. Borut |
From: Bernhard H. <ber...@be...> - 2004-01-05 22:42:13
|
> I actually have two things in mind, which have to be done before the > release: > - Setup on WIN32 should add the sddc bin path to the PATH env. variable > - I introduced the #pragma preproc_asm, which defines, if _asm blocks are > preprocessed or not. This was done by fixing #828015. > In the first version, the default was off, but then > we found out, that there are files in SDCC library sources, which have > #defines and #ifdef-ed code in _asm blocks. So I changed the default > to on. And that is the current situation. > > Now there several possibilities: > - to leave it as it is > - to set the default to off and remove preprocessed code from SDCC > library sources: > #defines can be replaced by asm EQUs, #ifdefs can be solved by > splitting big _asm blocks to smaller ones, so that #ifdefs will be outside > the _asm blocks. If we decide to do it: is there a volunteer to change > library sources? > - to set the default to off and include #pragma preproc_asm on in library > sources with preprocessor directives in _asm bocks. > The SDCC documentation should be updated (#pragma preproc_asm > documented), according to the decision. Thanks for pointing out this problem. I agree, that this should be fixed. But I don't think this is important enough to keep us from releasing the current sdcc. I feel a little bit responsible about this problem, because it was me, who poluted the _asm blocks with preprocessor directives. But I can't promise, if I can fix it some time. It might be helpfull to file a feature request as a reminder. Bernhard |
From: Borut R. <bor...@si...> - 2004-01-07 20:21:08
|
> - Setup on WIN32 should add the sddc bin path to the PATH env. variable Done. > - I introduced the #pragma preproc_asm, which defines, if _asm blocks are > preprocessed or not. This was done by fixing #828015. > In the first version, the default was off, but then > we found out, that there are files in SDCC library sources, which have > #defines and #ifdef-ed code in _asm blocks. So I changed the default > to on. And that is the current situation. > > Now there several possibilities: > - to leave it as it is > - to set the default to off and remove preprocessed code from SDCC > library sources: > #defines can be replaced by asm EQUs, #ifdefs can be solved by splitting > big _asm blocks to smaller ones, so that #ifdefs will be outside the > _asm blocks. If we decide to do it: is there a volunteer to change > library sources? > - to set the default to off and include #pragma preproc_asm on in library > sources with preprocessor directives in _asm bocks. > The SDCC documentation should be updated (#pragma preproc_asm documented), > according to the decision. Currently it seems, that the decision is to leave it as it is and to document it. Borut |
From: Jesus Calvino-F. <Je...@ec...> - 2004-01-05 21:48:15
|
Hi Bernhard, Yes, I concur a new release version may be convenient. By the way, what are the tasks/work required to produce a new release version? Jesus At 01:03 PM 1/4/2004, you wrote: >What do you think about a release? The last release is from 2001-09-29! IMHO >the current sdcc is the best we ever had. And it's certainly better than >2.3.0. > >Do you have anything on your disk, which must be in the next release? > >Bernhard |
From: Vangelis R. <vr...@ot...> - 2004-01-05 21:52:31
|
----- Original Message ----- From: "Bernhard Held" <ber...@be...> To: <sdc...@li...> Subject: [sdcc-devel] Release > What do you think about a release? The last release is from 2001-09-29! IMHO > the current sdcc is the best we ever had. And it's certainly better than > 2.3.0. > > Do you have anything on your disk, which must be in the next release? It would be nice if we started a new 'ChangeLog' file. It has reached around 150KB now. |
From: Bernhard H. <ber...@be...> - 2004-01-05 22:44:59
|
> It would be nice if we started a new 'ChangeLog' file. It has reached > around 150KB now. Hmm, I'm sure I've already seen ChangeLogs with much more than 1 MB. Does anybody know, what's usual? Opinions? Bernhard |
From: Paul S. <pa...@pj...> - 2004-01-05 23:11:42
|
I just tried the latest sdcc from cvs, and I hit want seems like a bug with using enum in structs (used to compile). I entered a bug report, which got assigned # 871258. Here's the sample code: http://www.pjrc.com/tmp/enum_test.c I'm not really an expert when it comes to what exactly is and isn't ANSI C... but my understanding was that enum is a primitive type like char, int, long and it's legal to use it within a struct. Maybe nobody really cares about enum? But if that code is ANSI compliant (gcc accepts it without warnings, even with "gcc -Wall -ansi -pedantic -c enum_test.c"), this seems like something that ought to get fixed before a release. Then again, maybe someone will explain ANSI's view of enum to me :-) Paul >What do you think about a release? The last release is from 2001-09-29! IMHO >the current sdcc is the best we ever had. And it's certainly better than >2.3.0. > >Do you have anything on your disk, which must be in the next release? > >Bernhard > > > |