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

Reply via email to