On Wed, 2007-12-26 at 10:46 +0000, Pedro Alves wrote: > Danny Backx wrote: > > As I said I had the complete build working on mingw32ce. But not > > everything was working yet, and after I did my changes, > > > And it appears that I didn't do a commit in all dirs yet (w32api and > > mingw were still missing). > > > > Let's try to keep the trunk building at all times, OK ? > If the change was incomplete, then you shouldn't have changed the > default target name in the build script.
That was the idea, except I found out too late that I'd forgotten to
commit some of the stuff. The build was working, and a whole bunch of
test programs compiled, linked, and worked just fine.
> Did I mention more than once already that I'd like to follow that Danny Smith
> has done with the latest MinGW gcc4.2.1 release?
> "* To throw exception across dll/exe boundaries in C++, you will need to
> link against the shared libgcc and libstdc++ runtime libs. To link
> against shared libgcc, add -shared-libgcc to command line. To link
> against shared libstdc++ add -lstdc++_s to command line. Hopefully, in
> future releases, the mechanism to seletc static or shared runtime libs
> can be improves. Unless you want to use auto-import to import data
> objects in libstdc++.dll, also add -D_DLL to commands line or #define
> _DLL in top-level headers. Again, this may chenage in future releases."
Not with this amount of detail, at least not to my knowledge.
> It is important for us to follow the same options MinGW uses.
>
> 1) Leverage their knowledge, understand their work. Our script was copied
> Danny already, but he has something new now.
This is certainly new to me.
> 2) Consistency with the big brother. In the future when those options start
> showing in MinGW ports of stuff, we'd have 0 porting effort.
> 3) Leave static runtime as default, so we don't pull the rug under our
> users feet.
I don't agree on all the assumptions here. In an earlier message you
replied to my question about use of build-mingw32ce-dll.sh that it was
insufficiently tested.
My motivations would be :
a. Get something working, get it out to the world so people can use it.
Hence my move *after* a release to start using build-mingw32ce-dll.sh
b. Try to minimize porting effort for yourself and for the people who
use it. (I'd like the effort to be 0 but I'm not counting on it.)
c. Provide a way for people who are wary of experimental stuff to avoid
it so they can choose for stability at all times.
I think your list and mine conflict "somewhat". Can we find a way ahead
that is "good" for both of us ?
Danny
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
