Hello, On Mon, 27 Dec 2010 14:32:54 +0000 Pedro Alves <alves....@gmail.com> wrote:
> On Saturday 25 December 2010 14:14:10, Paul Sokolovsky wrote: > > On Sat, 25 Dec 2010 12:46:08 +0000 > > Pedro Alves <alves....@gmail.com> wrote: > > > > > On Friday 24 December 2010 22:22:56, Paul Sokolovsky wrote: > > > > Hello, > > > > > > > > Anyone can explain me meanings and differences between > > > > _WIN32_CE & UNDER_CE ? UNDER_CE is not defined by CeGCC, while > > > > used for some #ifdefs. I'm going to replace these with > > > > _WIN32_CE in my clean up work so far. > > > > > > Would be useful to know what is it you're thinking you're > > > cleaning up. > > > > Hello Pedro, nice to have your attention ;-). I recently sent > > several mails to the list pondering how to make what cegcc achieved > > more maintainable. In short, my ideas were: extract patches from > > cegcc svn repo, clean them up to contain only wince-pertinent > > changes and optimize for size (change as little as possible), > > Hello! :-) > > IIRC, the w32api wince changes compared to upstream aren't that many > or that invasive that cause trouble when merging from upstream. Actually, I have to agree, using such objective criteria, as patch size, or number of actual conflicts experienced. I now finished 1st round of my cleanup, and was able to cut size only from 120K to 115K. I also had just one conflict upgrading to w32api CVS HEAD. But there's more involved criterion as maintainability, and I believe my changes improved it. That said, I'll probably will be less vigorous with in-depth cleanup with other components, instead will try to set git repos for each first. > The > scheme I was following, was that I kept the CVS (metadata) directories > in our svn repository, so a merge from upstream is literally just a > regular cvs update, and whole diff from upstream is just a "cvs diff". Yes, I got that, that's how I produced w32api-cegcc patchset: cvs -z9 diff -u -w -B >diff_w_B.diff (-w -B are part of my "cleanup" plan). Except that it involves dealing with CVS and its quirks (which I for example already forgot for good), and lacking base-level DSCM goodness, like ability to get that diff immediately, with or without network. > > > then use modern SCM > > which allows to track upstream close and maintained changes in > > flexible manner (read: git). > > > > I currently try to to this for w32api, following procedure I > > outlined at > > http://article.gmane.org/gmane.comp.gnu.cegcc.devel/3163 (even > > though I already see drawbacks there). > > I haven't looked at your git tree, Yeah, I actually didn't announce it yet, though pushed already and started to describe. It's here: https://sourceforge.net/apps/trac/cegcc/wiki/Git%20Migration (feel free to skip blurb, to "Draft w32api Repository"). > but I'm not sure what we'd be > really buying with your suggestion. Instead of adding/removing > ifdefs, we're now actually _changing_ declarations, which is > troublesome in its own way at merge time. It also hides things from > grep and from users when the compiler/IDEs points "wrong arguments, > here's the declaration", so I'm not convinced it's a change we want. I'm not sure what you exactly mean, as I meant procedure of migrating w32api-cegcc changes to git in such a way as to track upstream closely, which is at the link above. I guess, you comment on _WNAME() macro which I proposed in another mail. Well, one can utter such arguments against it (I already hear them from GNU bureaucrats ;-) ), but they are not very stable: 1. Changing existing declaration => problem of conflicts. Yes, if that declaration will be updated in upstream, there will be conflict. But there's much less chance that declaration will be added than what new will be added (w32api is still lacking) - right where one of dozen ifdefs is planted. 2. Grep unfriendly? Why, grep for "Shell_NotifyIcon" and you'll find what you want. What, you grep for "Shell_NotifyIcon("? Oops, then in the original w32api you also won't find anything, there's only Shell_NotifyIconA( and Shell_NotifyIconW(. 3. Compiler error line numbers? Oops, when programming for win32, you used "Shell_NotifyIcon" in your code and compiler pointed you at "Shell_NotifyIconA" or "Shell_NotifyIconW". Gotta learn what that means. Manageable? Then looking up what _WNAME means couple of times and remembering that should be too. 2&3 show that w32api already not that obvious. But _WNAME is at least clean change on messy base (it does one specific thing in one specific way). While #ifdef's are messy change on messy base, let me give more examples why (in addition to type example I gave before, I saw couple more already IIRC). There're different structural variants used, like: #ifdef _WIN32_WCE void foo(); #else void fooA(); void fooW(); #endif and #ifndef _WIN32_WCE void fooA(); void fooW(); #else void foo(); #endif then, if few goes in row, they are grouped together. Then there're 2 groups with thin layer, like: #ifdef _WIN32_WCE void foo1(); void foo2(); .. #endif void bar1(); #ifdef _WIN32_WCE void baz1(); void baz2(); .. #endif Then human editor tries to "optimize" that by moving upstream line at the top and merging #ifdef chunks, and that goes in rounds and rounds, without criteria to converge. On the other hand, again, _WNAME does just what it does, line-local, and there's no proverbial "there's more than one way to do that". Final argument is that it's possible to produce #ifdef's from _WNAME (when wince support will stabilize or upstream will play up), but not the other way around, per examples above. > > > Ok, sounds good, rules for mingw are clear. But original question > > popped up while looking at w32api: > > > > $ grep -r -n UNDER_CE --exclude-dir=.svn w32api/include/ > > w32api/include/ws2tcpip.h:44:#ifdef UNDER_CE > > w32api/include/winbase.h:813:#ifdef UNDER_CE > > w32api/include/winbase.h:1189:#ifndef UNDER_CE > > Agreed. The winbase.h:813 change (r1278) should have never gone > in like that though :-( :-( Yeah, caught my attention too. https://github.com/pfalcon/cegcc-w32api-try1/commit/47e68fa3391758aa4e3352a6916ac06c649278a4 > > > r1278 | dannybackx | 2009-05-18 11:57:49 +0100 (Seg, 18 Mai 2009) | > > 2 linhas > > > > Definition for CE for CRITICAL_SECTION taken from > > http://fpc.freedoors.org/fpc-2.2.0.source/rtl/win/sysosh.inc under > > LGPL license. > > Argh. LGPL code in w32api headers is not allowed. :-/ > > > > > $ grep -r -n _WIN32_WCE --exclude-dir=.svn w32api/include/ | wc -l > > 174 > > > > As w32api defines _WIN32_WCE first thing and already uses it in 99% > > cases, maybe it should use it exclusively? > > Sure. https://github.com/pfalcon/cegcc-w32api-try1/commit/be2a26d09e971f81dee8b4787e30ab06d9707eff > > -- > Pedro Alves -- Best regards, Paul mailto:pmis...@gmail.com ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
