Danny Backx wrote: > On Sat, 2007-06-02 at 17:45 +0100, Pedro Alves wrote: >> What do you think of releasing a 1.0 in a near future? > > No objection, but I'd suggest a couple of steps in between. Now that you > have the arm-unknown-mingw32ce accepted, we need to change. I don't see > many arguments to put this in another than the next release we do. > > My suggestion : > >> Here's what I think should be done before 1.0: >> >> * Rename arm-wince-mingw32ce to arm-unknown-mingw32ce. >> * Rename arm-wince-cegcc to arm-unknown-cegcc too. > > The above could be in a 0.50 >
Sure. >> * Either import a recent gdb from cvs and commit the dll patches support >> on top (maintainance burden), or remove gdb from our svn, and add tar.gz >> snapshots into the downloads section [1]. If we do this now, we will have >> a gdbserver that will be future gdb releases, because the dll support >> part of the remote protocol is currently in discussion and will surelly >> change. We need the new gdb so people with 64-bit OSen, or with non x86 >> archs can use gdb. > > This could be in a 0.60 > I missed a few key words there. I meant to write: > a gdbserver that will be *incompatible with* future gdb releases, because the > And then I think some the stuff below is too big to put in a 0.60 -> 1.0 > change. So a 1.0 could be 0.60 + whatever small stuff comes in at the > time. The advantage from this approach would be that 1.0 could actually > be stable. > OK. >> * Do a w32api and mingw upstream sync. (can be delayed). >> >> [1] - as we have less and less divergence from upstream packages, we >> should remove our versions from svn. binutils still has a few minor >> patches left to submit (ld stuff, from the top of my head). >> binutils 2.18 is going to be released soon I think, so we should >> submit our patches before the release. I'm in the process of >> flushing stuff to gdb, and finishing that is currenly >> dependent on work from Daniel Jacobowitz, but I'm hoping that to be >> finished in the following weeks. >> >> Post 1.0: >> >> * Submit gcc changes upstream (mingw32ce). >> * Move to gcc-4.2 or gcc-4.3. >> * Perhaps split monolithic releases (gcc+binutils+gdb+newlib+w32api+mingw) >> into separate component releases. At least the mingw+w32api should be >> split so one can release the runtimes more often. Of course we can >> still have major all-in-one bundled releases from time to time. >> >>> How do you think we should go about version numbering ? It's been a >>> while since we made a release, maybe it's time to do a joint one (linux >>> + cygwin) and obviously use the same version number for both. >>> >> I think we should have *source* releases, and then do binary >> builds of those - we can have linux and Cygwin easily, and maybe >> someone will contribute MacOS versions too. I would like to have >> MinGW hosted binaries too, but someone would have to step in to >> do it. > > Some of this requires us to talk about what we put in our SVN, whether > we need to change our current model of SVN is not clear to me; > apparently it is to you. I see two possible approach changes : > - change SVN contents (as you indicate) > - change our release contents (distribute only the stuff that's not > in GNU projects), and as you say : in source > I'm not clear too. But to me, ideally, we wouldn't have the less possible in our svn. Everything would be submitted/committed upstream, and we would distribute tar.gz's + scripts to build the packages. I don't see any barriers for all of binutils, gdb and gcc to be submitted. newlib, w32api and mingw will be harder. Actually, I don't think we should ever submit our newlib port. As for w32api and mingw, having it integrated in the src/winsup package, will take some work and lobbying :) > The release content change might also require us to include a patch or > two for the other packages (e.g. if we would like to keep my > -fcoverage-base code, but the gcc folks lag in including it). Your gdb > work is a more obvious example. > We can always have tar.gz + patches. The gdb work is going into cvs eventually, so no problem there. Since I have commit access on the gdb land, I don't see myself working against our svn version. I'd ratter have cvs snapshots in our download section. Much easier (for me), than constantly syncing our version with upstream. If somebody sends us a WinCE specific patch, we simply redirect them to [EMAIL PROTECTED] Of course, if someone else is willing to do that (the syncing), be my guest, but I think it is a waste of valuable resources. > As I said we need to talk about this, consider what I wrote here to be > food for thought, open for discussion. > >> Building in Cygwin is no different from building in linux. Cygwin is >> just another unix that happens to be implemented on top on Windows. >> I'd say, merge the building on linux with building on Cygwin sections >> into a just "building" section. Also, we need to better split the >> documentation of cegcc and mingw32ce. > > I'll look into the docs. > > Danny ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
