cegcc-devel — Discussion about CeGCC development

Re: [Cegcc-devel] Upstreaming patches

[<dan...@sc...>]

Read the value in an article somewhere, insufficiently verified.

  Danny

> -#define PSH_MAXIMIZE    0x2000  /* ?? */
> 
> 1) Why is there such comment ?

Ask Danny, that was his commit.

Dan...@sc... - http://danny.backx.info
Verzonden van mijn HTC

Re: [Cegcc-devel] _WIN32_WCE vs UNDER_CE

[Paul S. <pm...@gm...>]

Hello,

On Mon, 27 Dec 2010 18:30:01 +0200
Paul Sokolovsky <pm...@gm...> wrote:

[]
> > > 
> > > $ 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

Figured this issue, UNDER_CE usage comes from upstream, so will revert
this patch, as rule "Don't patch upstream without real necessity"
prevails "Have 100% consistency".


-- 
Best regards,
 Paul                          mailto:pm...@gm...

Re: [Cegcc-devel] Upstreaming patches

[Paul S. <pm...@gm...>]

Hello,

On Tue, 28 Dec 2010 10:43:13 +0100 (CET)
Vincent Torri <vt...@un...> wrote:

> 
> 
> On Mon, 27 Dec 2010, Paul Sokolovsky wrote:
> 
> > https://github.com/pfalcon/cegcc-w32api-try1/commit/dba53b839e04067d0ed319b61e9e61a3b24bd544
> 
> -#define PSH_MAXIMIZE    0x2000  /* ?? */
> 
> 1) Why is there such comment ?

Ask Danny, that was his commit.

> 2) maybe you should let the comment in the code, even with a FIXME

Well, I'm doing mindful, attentive cleanup, not just dumb cut&pasting.
I cannot pledge to have scrutinized every changed line (there're 100Kb
after all), but that's essentially what I do for every small hunk -
either get rid of a change line in it, or justify it's necessity (and
that's b@tchy job, can't believe I volunteered for that ;-)). In this
case I verified that the value seems correct (using multi-score method
described in yesterday's mail), and as that apparently can be the only
question for a simple define, removed a mark.

> 
> Vincent Torri



-- 
Best regards,
 Paul                          mailto:pm...@gm...

Re: [Cegcc-devel] CeGCC for Windows (without bein forced to use cygwin)

[Stefan P. <ste...@gm...>]

Hi,

Thank you so much!
I will try both, the binary snapshot and my own build ( If I am able to 
manage this ;-) ) with your build script.

Regards
Stefan Partheymüller

>             
> -------- Original-Nachricht --------
> Datum: Tue, 28 Dec 2010 11:06:21 +0100
> Von: "Sébastien Lorquet" <sq...@gm...>
> An: ceg...@li...
> CC: "Stefan Partheymüller" <ste...@gm...>
> Betreff: Re: [Cegcc-devel] CeGCC for Windows (without bein forced to use 
> cygwin)
> 
>             Hi,
> 
> Okay, maybe that's an EOL problem.
> but the patch is so simple you could apply it by hand.
> 
> I created the --gmp and --mpfr options, then passed the values to
> --with-gmp in gcc 's ./configure
> 
> you could hardcode that for a quick test.
> BTW, I attached the script I used there, that you can also find (until
> I format my server again...) here:
> So you want the file:
> 
> http://www.unsads.com/~squalyl/cegcc/cegcc-src/cegcc/src/scripts/build-mingw32ce.sh
> The binary snapshot is there:
> http://www.unsads.com/~squalyl/cegcc/mingw32ce-build-mingw.zip
> 
> Sebastien
> 
> On Tue, Dec 28, 2010 at 10:21 AM, "Stefan Partheymüller"
> <ste...@gm...> wrote:
> > Hi, I tried to build CeGCC for Windows like explained, but I have a 
> problem
> > with patching the build script. When I try to patch it, with the patch 
> tool
> > like this:
> >
> > patch -p0 -i patch.diff
> >
> > The following errors occur:
> >
> > patching file build-mingw32ce.sh
> > Hunk #1 FAILED at 49.
> > Hunk #2 FAILED at 97.
> > Hunk #3 FAILED at 179.
> > Hunk #4 FAILED at 209.
> > Hunk #5 FAILED at 314.
> > Hunk #6 FAILED at 333.
> > 6 out of 6 hunks FAILED -- saving rejects to file 
> build-mingw32ce.sh.rej
> >
> > Sorry I don't know much about this tool...
> >
> >
> > --
> > NEU: FreePhone - kostenlos mobil telefonieren und surfen!
> > Jetzt informieren: http://www.gmx.net/de/go/freephone
> > 
> ------------------------------------------------------------------------------
> > 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
> > Ceg...@li...
> > https://lists.sourceforge.net/lists/listinfo/cegcc-devel
> >
> >
> 
        
-- 
NEU: FreePhone - kostenlos mobil telefonieren und surfen!			
Jetzt informieren: http://www.gmx.net/de/go/freephone

Re: [Cegcc-devel] CeGCC for Windows (without bein forced to use cygwin)

[Sébastien L. <sq...@gm...>]

Hi,

Okay, maybe that's an EOL problem.
but the patch is so simple you could apply it by hand.

I created the --gmp and --mpfr options, then passed the values to
--with-gmp in gcc 's ./configure

you could hardcode that for a quick test.
BTW, I attached the script I used there, that you can also find (until
I format my server again...) here:
So you want the file:
http://www.unsads.com/~squalyl/cegcc/cegcc-src/cegcc/src/scripts/build-mingw32ce.sh
The binary snapshot is there:
http://www.unsads.com/~squalyl/cegcc/mingw32ce-build-mingw.zip

Sebastien

On Tue, Dec 28, 2010 at 10:21 AM, "Stefan Partheymüller"
<ste...@gm...> wrote:
> Hi, I tried to build CeGCC for Windows like explained, but I have a problem
> with patching the build script. When I try to patch it, with the patch tool
> like this:
>
> patch -p0 -i patch.diff
>
> The following errors occur:
>
> patching file build-mingw32ce.sh
> Hunk #1 FAILED at 49.
> Hunk #2 FAILED at 97.
> Hunk #3 FAILED at 179.
> Hunk #4 FAILED at 209.
> Hunk #5 FAILED at 314.
> Hunk #6 FAILED at 333.
> 6 out of 6 hunks FAILED -- saving rejects to file build-mingw32ce.sh.rej
>
> Sorry I don't know much about this tool...
>
>
> --
> NEU: FreePhone - kostenlos mobil telefonieren und surfen!
> Jetzt informieren: http://www.gmx.net/de/go/freephone
> ------------------------------------------------------------------------------
> 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
> Ceg...@li...
> https://lists.sourceforge.net/lists/listinfo/cegcc-devel
>
>

Re: [Cegcc-devel] Upstreaming patches

[Vincent T. <vt...@un...>]

On Mon, 27 Dec 2010, Paul Sokolovsky wrote:

> https://github.com/pfalcon/cegcc-w32api-try1/commit/dba53b839e04067d0ed319b61e9e61a3b24bd544

-#define PSH_MAXIMIZE    0x2000  /* ?? */

1) Why is there such comment ?
2) maybe you should let the comment in the code, even with a FIXME

Vincent Torri

Re: [Cegcc-devel] CeGCC for Windows (without bein forced to use cygwin)

[Stefan P. <ste...@gm...>]

Hi, I tried to build CeGCC for Windows like explained, but I have a problem 
with patching the build script. When I try to patch it, with the patch tool 
like this:

patch -p0 -i patch.diff

The following errors occur:

patching file build-mingw32ce.sh
Hunk #1 FAILED at 49.
Hunk #2 FAILED at 97.
Hunk #3 FAILED at 179.
Hunk #4 FAILED at 209.
Hunk #5 FAILED at 314.
Hunk #6 FAILED at 333.
6 out of 6 hunks FAILED -- saving rejects to file build-mingw32ce.sh.rej

Sorry I don't know much about this tool...    
-- 
NEU: FreePhone - kostenlos mobil telefonieren und surfen!			
Jetzt informieren: http://www.gmx.net/de/go/freephone

[Cegcc-devel] Upstreaming patches

[Paul S. <pm...@gm...>]

Hello,

As if heavens select good time to add a bit of controversy, I've just
got reply from upstream for the patch I just couldn't drop silently in
my cleanup (and also it was kind of poke at them if they actually
process patches):

https://sourceforge.net/tracker/index.php?func=detail&aid=3139241&group_id=2435&atid=302435

Well, will be a good test case for how well git cvsimport works ;-).

And they're there and reasonably responsive. There're two other patches
which I did clean up from my branch (as they are not directly related to
real wince functionality, so should not be subject of maintenance for
wince cross-compiler):

https://github.com/pfalcon/cegcc-w32api-try1/commit/c66d8ab22bb44287c48a1f46349bb0ca514cae8f
https://github.com/pfalcon/cegcc-w32api-try1/commit/dba53b839e04067d0ed319b61e9e61a3b24bd544

Anybody bothers to submit them?

Note 1: these are reverse patches (i.e. once forward patch was applied
to upstream, I applied reverse patch to bring it back to upstream).
Note 2: if you'll submit dba53b839e, note that hex conversion for
PSH_WATERMARK is wrong. Which should be another hint why any changes to
upstream should be minimal, if not avoided.


-- 
Best regards,
 Paul                          mailto:pm...@gm...

[Cegcc-devel] [patch] Don't pass inst_* from w32api top Makefile down to sub-Makefile

[Paul S. <pm...@gm...>]

Pedro,

While we're on conversation, I'd better ask you to review the following
commit:

https://github.com/pfalcon/cegcc-w32api-try1/commit/5c5e4e1e993443136ab24f721a1538d5ef4b64cb

They issue, inst_* are subdirectories' Makefile vars, which compute
their values themselves. They don't seem to be initialized by configure
or top Makefile (even can't, as they are per-subdir), so top Makefile
passes empty values on command line to sub-Makefiles, which override
their own calculation of values, and causes them to execute commands
like "mkdir -p" (empty path).

I have no idea why *sometimes* it works (like when running
build-mingw32ce.sh), but it fails building w32api standalone.

-- 
Best regards,
 Paul                          mailto:pm...@gm...

Re: [Cegcc-devel] _WIN32_WCE vs UNDER_CE

[Paul S. <pm...@gm...>]

Hello,

On Mon, 27 Dec 2010 20:55:49 +0200
Paul Sokolovsky <pm...@gm...> wrote:

[]
> Everyone's mileage will vary, though. I'm not interested in
> upstreaming (I know all this mumbo-jumbo oh so well), so mingw's
> specific mileage won't hurt me much. That said, I hereby confirm that
> I know of such issues and am doing reasonable effort to follow
> upstream's guidelines on the matter. I also know that Pedro Alves and
> Danny Backx are aware of these issues and did their reasonable effort
> to comply either, so I take their code "as is" as the basis for my

"their code" == "code they maintained"

> work. Specific cases may be considered later.

-- 
Best regards,
 Paul                          mailto:pm...@gm...

Re: [Cegcc-devel] _WIN32_WCE vs UNDER_CE

[Paul S. <pm...@gm...>]

Hello,

On Mon, 27 Dec 2010 18:26:53 +0000
Pedro Alves <alv...@gm...> wrote:

> On Monday 27 December 2010 18:19:59, Paul Sokolovsky wrote:
> > Btw, while looking at vendor source may be considered questionable
> > practice, because vendor source access is granted by a license which
> > itself, and its licensing process (like changes evolution), don't
> > receive enough 3rd-party review (and thus may contain really funky
> > things), I consider that (L)GPL and its motivation is sufficiently
> > known to public, so looking at (L)GPL texts to get knowledge is ok.
> 
> No it's not.  <http://www.mingw.org/wiki/SubmitPatches>, point 8.

You probably misread, Pedro, they talk about source, and I'm about
knowledge. I consider it to be a different matter to do dumb cut&paste
and reading an electronic book, even if it's Chinese or C++, to get
understanding of some subject. For example, I could study question of
process synchronization and even remember key points like object member
names, though I doubt I'd remember footnotes or comments, word by word,
or at all. Also, it seems that using LGPL source is allowed after all:
they prohibit GPL and LPGL (sic!).

Everyone's mileage will vary, though. I'm not interested in
upstreaming (I know all this mumbo-jumbo oh so well), so mingw's
specific mileage won't hurt me much. That said, I hereby confirm that I
know of such issues and am doing reasonable effort to follow upstream's
guidelines on the matter. I also know that Pedro Alves and Danny Backx
are aware of these issues and did their reasonable effort to comply
either, so I take their code "as is" as the basis for my work. Specific
cases may be considered later.

> 
> -- 
> Pedro Alves



-- 
Best regards,
 Paul                          mailto:pm...@gm...

Re: [Cegcc-devel] _WIN32_WCE vs UNDER_CE

[Pedro A. <alv...@gm...>]

On Monday 27 December 2010 18:19:59, Paul Sokolovsky wrote:
> Btw, while looking at vendor source may be considered questionable
> practice, because vendor source access is granted by a license which
> itself, and its licensing process (like changes evolution), don't
> receive enough 3rd-party review (and thus may contain really funky
> things), I consider that (L)GPL and its motivation is sufficiently
> known to public, so looking at (L)GPL texts to get knowledge is ok.

No it's not.  <http://www.mingw.org/wiki/SubmitPatches>, point 8.

-- 
Pedro Alves

Re: [Cegcc-devel] _WIN32_WCE vs UNDER_CE

[Paul S. <pm...@gm...>]

Hello,

On Mon, 27 Dec 2010 18:16:48 +0100 (CET)
Vincent Torri <vt...@un...> wrote:

> 
> Hey,
> 
> On Mon, 27 Dec 2010, Paul Sokolovsky wrote:
> 
> > https://github.com/pfalcon/cegcc-w32api-try1/commit/be2a26d09e971f81dee8b4787e30ab06d9707eff
> 
> shouldn't the critical section be removed if (L)GPL code is not
> allowed instead of replacing UNDER_CE by WIN32_WCE (first change) ?

Following commit was in regard to CRITICAL_SECTION:

https://github.com/pfalcon/cegcc-w32api-try1/commit/47e68fa3391758aa4e3352a6916ac06c649278a4

Internally, I removed it, then did some googling (mostly looked at the
search highlight excerpts), friend phoning, few debugging sessions. In
the end, it seemed that structure was laid out right, just comments
were dubious.

Btw, while looking at vendor source may be considered questionable
practice, because vendor source access is granted by a license which
itself, and its licensing process (like changes evolution), don't
receive enough 3rd-party review (and thus may contain *really* funky
things), I consider that (L)GPL and its motivation is sufficiently
known to public, so looking at (L)GPL texts to *get knowledge* is ok.

It's like, some time ago I read in some glossy magazine that wearing
specific model of hat in some specific way would protect my ears from
frost much better than anything else. Not common knowledge on its own.
And I couldn't copy and sell their magazine on my own, in full or in
part, or copy that article to other magazine. But I use that knowledge
since then, including in public, and wasn't requested to stop doing
that or pay royalties. That's because that magazine is like all
other magazines, and they don't do things like that. And there are many
projects which use (L)GPL and stopping spreading of knowledge is not
known to be among their aims. And it's different from the vendor, which
has its proprietary license, motives of which are less clear.

> 
> Vincent Torri


-- 
Best regards,
 Paul                          mailto:pm...@gm...

Re: [Cegcc-devel] _WIN32_WCE vs UNDER_CE

[Vincent T. <vt...@un...>]

Hey,

On Mon, 27 Dec 2010, Paul Sokolovsky wrote:

> https://github.com/pfalcon/cegcc-w32api-try1/commit/be2a26d09e971f81dee8b4787e30ab06d9707eff

shouldn't the critical section be removed if (L)GPL code is not allowed 
instead of replacing UNDER_CE by WIN32_WCE (first change) ?

Vincent Torri

Re: [Cegcc-devel] _WIN32_WCE vs UNDER_CE

[Paul S. <pm...@gm...>]

Hello,

On Mon, 27 Dec 2010 14:32:54 +0000
Pedro Alves <alv...@gm...> wrote:

> On Saturday 25 December 2010 14:14:10, Paul Sokolovsky wrote:
> > On Sat, 25 Dec 2010 12:46:08 +0000
> > Pedro Alves <alv...@gm...> 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:pm...@gm...

Re: [Cegcc-devel] _WIN32_WCE vs UNDER_CE

[Pedro A. <alv...@gm...>]

On Saturday 25 December 2010 14:14:10, Paul Sokolovsky wrote:
> On Sat, 25 Dec 2010 12:46:08 +0000
> Pedro Alves <alv...@gm...> 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.  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".

> 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, 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.

> 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 :-( :-(

> 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.

-- 
Pedro Alves

[Cegcc-devel] Git hosting

[Paul S. <pm...@gm...>]

Hello,

I confirmed that SF.net supports multiple git repos per project, see
https://sourceforge.net/apps/ideatorrent/sourceforge/ideatorrent/idea/59/
https://sourceforge.net/apps/trac/sourceforge/wiki/Git#CreatingMultipleRepositories

So, separate gcc/binutils/w32api/mingw/gdb repos can be pretty well
hosted on SF, within bounds of the original project.

That said, I'll probably do initial pushes of w32api git migration I'm
working on to github, to test out stuff.

-- 
Best regards,
 Paul                          mailto:pm...@gm...

Re: [Cegcc-devel] _WIN32_WCE vs UNDER_CE

[Paul S. <pm...@gm...>]

Hello,

On Sat, 25 Dec 2010 12:46:08 +0000
Pedro Alves <alv...@gm...> 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), 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).

> 
> UNDER_CE is a builtin define (defined by the compiler).  You can use
> it to check whether you're targetting Windows CE, even if you haven't
> included any header in your compilation unit.

Ok, I see, it is set up in your mingw32ce-gcc_20091228_r155193.diff
patch.

> 
> There is no _WIN32_CE, you mean _WIN32_WCE (I've now fixed the

Yes, sure, that's a typo.

> $subject). _WIN32_WCE is the equivalent of _WIN32_WINNT on desktop
> Windows.  You define it to the WinAPI version you want to target
> (e.g., 0x500), either on something like CFLAGS, or before including
> any w32api header.  If you don't define it to anything, the w32api
> headers define it to a default conservative Windows CE version.
> 
> Then, there's __COREDLL__ (for coredll.dll).  This is defined by the
> compiler, and it selects the C runtime.  On Desktop Windows, this
> would be either __MSVCRT__ (for msvcrt.dll), or __CRTDLL__ (legacy,
> for crtdll.dll).  Early versions of Windows CE had some other C
> runtime dll (I can't remember which now).  In mingw/ code, you always
> use __COREDLL__, _WIN32_WCE is verbotten there.

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

$ 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?

> 
> -- 
> Pedro Alves



-- 
Best regards,
 Paul                          mailto:pm...@gm...

Re: [Cegcc-devel] _WIN32_WCE vs UNDER_CE

[Pedro A. <alv...@gm...>]

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.

UNDER_CE is a builtin define (defined by the compiler).  You can use it
to check whether you're targetting Windows CE, even if you haven't
included any header in your compilation unit.

There is no _WIN32_CE, you mean _WIN32_WCE (I've now fixed the $subject). 
_WIN32_WCE is the equivalent of _WIN32_WINNT on desktop Windows.  You define
it to the WinAPI version you want to target (e.g., 0x500), either on
something like CFLAGS, or before including any w32api header.  If you
don't define it to anything, the w32api headers define it to a default
conservative Windows CE version.

Then, there's __COREDLL__ (for coredll.dll).  This is defined by the
compiler, and it selects the C runtime.  On Desktop Windows, this would
be either __MSVCRT__ (for msvcrt.dll), or __CRTDLL__ (legacy, for
crtdll.dll).  Early versions of Windows CE had some other C runtime
dll (I can't remember which now).  In mingw/ code, you always
use __COREDLL__, _WIN32_WCE is verbotten there.

-- 
Pedro Alves

Re: [Cegcc-devel] _WIN32_WCE vs UNDER_CE

[Pedro A. <alv...@gm...>]

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.

UNDER_CE is a builtin define (defined by the compiler).  You can use it
to check whether you're targetting Windows CE, even if you haven't
included any header in your compilation unit.

There is no _WIN32_CE, you mean _WIN32_WCE (I've now fixed the $subject). 
_WIN32_WCE is the equivalent of _WIN32_WINNT on desktop Windows.  You define
it to the WinAPI version you want to target (e.g., 0x500), either on
something like CFLAGS, or before including any w32api header.  If you
don't define it to anything, the w32api headers define it to a default
conservative Windows CE version.

Then, there's __COREDLL__ (for coredll.dll).  This is defined by the
compiler, and it selects the C runtime.  On Desktop Windows, this would
be either __MSVCRT__ (for msvcrt.dll), or __CRTDLL__ (legacy, for
crtdll.dll).  Early versions of Windows CE had some other C runtime
dll (I can't remember which now).  In mingw/ code, you always
use __COREDLL__, _WIN32_WCE is verbotten there.

-- 
Pedro Alves

Re: [Cegcc-devel] _WIN32_CE vs UNDER_CE

[Vincent T. <vt...@un...>]

Hey

> 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.

http://www.pocketpcjunkies.com/Uwe/Forum.aspx/wince-vc/3273/UNDER-CE-vs-WIN32-WCE

quote:

"> 1) I determine whether I'm compiling for CE by checking whether
> UNDER_CE is defined
> 2) If I need to know which version of CE is the target, I do
> comparisons with _WIN32_WCE

That is consistent with what I have seen in SDK headers and elsewhere. 
Thank
you for this good advise."

cheers and merry christmas

Vincent Torri

[Cegcc-devel] _WIN32_CE vs UNDER_CE

[Paul S. <pm...@gm...>]

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.

-- 
Best regards,
 Paul                          mailto:pm...@gm...

[Cegcc-devel] Mediawiki migrated to Trac

[Paul S. <pm...@gm...>]

Hello,

Per previous proposal, and no concerns sounded (also asked Danny
explicitly), I've enabled and set up Trac instanace for CeGCC project
at: https://sourceforge.net/apps/trac/cegcc/

Project admins were given Trac admin privileges, members - to maintain
tickets, and all registered sf.net users can submit tickets and
create/edit wiki pages.

I also migrated (manually) Mediawiki pages (cleaned it up there first)
and rewrote front page to give more insight into project and wiki
contents. I'm in the process of further cleaning up/elaborating wiki at
this time.

Trac has built in Manual/Help, accessible at
https://sourceforge.net/apps/trac/cegcc/wiki/TracGuide (or via
Help/Guide link on each page). In particular, wiki syntax is described
here: https://sourceforge.net/apps/trac/cegcc/wiki/WikiFormatting . It
is close to Mediawiki, though less HTMLish (and thus less powerful,
though more readable).

Further course of action:

1. Add notice to Mediawiki pages that they were migrated.
2. Disable write access to Mediawiki (if possible).
3. Add notice to SF tracker that bugs should be submitted to Trac.
4. As time permits, migrated existing SF bugs to Trac (at least create
cross-links.)


Merry Christmas!

-- 
Best regards,
 Paul                          mailto:pm...@gm...

Re: [Cegcc-devel] 'doze comes to ARMs in full

[Craig V. <cra...@gm...>]

This is truly hilarious.  Microsoft is once again showing us that they
JUST DON'T GET IT.

At some point in the near future they're going to have to do something
innovative and compelling or they're finished.

Running "full Windows" on mobile devices is not what I'm talking about
either.  WHERE is the innovation?

Happy Holidays, everyone..
Craig

On Thu, Dec 23, 2010 at 2:17 PM, Paul Sokolovsky <pm...@gm...> wrote:
> Hello,
>
> http://www.eetimes.com/electronics-news/4211666/ARM-share-price-soars-on-Windows-reports
>
>
> --
> Best regards,
>  Paul                          mailto:pm...@gm...
>
> ------------------------------------------------------------------------------
> 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
> Ceg...@li...
> https://lists.sourceforge.net/lists/listinfo/cegcc-devel
>

[Cegcc-devel] 'doze comes to ARMs in full

[Paul S. <pm...@gm...>]

Hello,

http://www.eetimes.com/electronics-news/4211666/ARM-share-price-soars-on-Windows-reports


-- 
Best regards,
 Paul                          mailto:pm...@gm...