Danny Backx wrote: > You'll see that I've submitted my -fcoverage-base code to svn. In an > earlier exchange you didn't feel well about reviewing changes to gcc > code so I skipped that phase. If you have comments now, don't hesitate. >
I've seen it, I'm subscribed there. Since you've asked: My comment is that you have ifdef UNDER_CE (the MessageBox) code, that will surely be rejected. My advice is to remove that hunk, and keep it on our version for the time being (is it really needed?) Also, be prepared for some review delay and patch pinging every two weeks or so. Also notice that the gcc patch policy expects one too do a full bootstrap and run the testsuite before a patch is applied [1]. If you're lucky, you won't be asked to. Just a warning, cause I see gcc newbies there complaining all the time :) [0] http://gcc.gnu.org/contribute.html > I've implemented the Makefile change (libstdc++) as you said, and reran > my RPM build for both cegcc and mingw32ce. Both succeeded. > Thanks. I forgot that say in the previous mail, but if it wasn't clear, the problem with the quotes was that the linker was looking for a file named "-lcegcc -lcoredll" instead of the two libs. > We haven't talked about version numbers lately, and this was one of the > things you complained about when we had our infamous fight. > What do you think of releasing a 1.0 in a near future? 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. * 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. * 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. > I'll also have another look at our documentation, that also is probably > long overdue. > 'long' is a diminutive :) > Would you have a look at cygwin specific build instructions ? I am not > well positioned to write them. > 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. And a serious question. Am I right in saying that you use more of cegcc than mingw32ce? I would like to know why - what feature from cegcc do you use the most, that doesn't exist in mingw32ce, because of its native aspect. Cheers, Pedro Alves ------------------------------------------------------------------------- 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
