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
> * 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
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.
> * 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
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.
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
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
