Re: Defs for GetSystemPowerStatusEx2

One more patch.  This implements the definitions for the less capable
GetSystemPowerStatusEx command.

Definitions are from:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceshellui5/html/wce50lrfGetSystemPowerStatusEx.asp

and:

http://msdn.microsoft.com/library/en-us/wceshellui5/html/wce50lrfsystempowerstatusex.asp

-Kevin

2006-12-02  Kevin O'Connor  <kevin@...>

        * include/winbase.h: Add SYSTEM_POWER_STATUS_EX structure.
          Add GetSystemPowerStatusEx function definition.

Index: src/w32api/include/winbase.h
===================================================================
--- src/w32api/include/winbase.h	(revision 835)
+++ src/w32api/include/winbase.h	(working copy)
 <at>  <at>  -993,6 +993,20  <at>  <at> 
       BYTE bCertificate[1];
 } WIN_CERTIFICATE, *LPWIN_CERTIFICATE;
 #ifdef _WIN32_WCE
+typedef struct _SYSTEM_POWER_STATUS_EX {
+  BYTE ACLineStatus;
+  BYTE BatteryFlag;
+  BYTE BatteryLifePercent;

Re: Defs for GetSystemPowerStatusEx2

Applied, thanks.

	Danny

On Sat, 2006-12-02 at 13:35 -0500, Kevin O'Connor wrote:
> One more patch.  This implements the definitions for the less capable
> GetSystemPowerStatusEx command.
> 
> Definitions are from:
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceshellui5/html/wce50lrfGetSystemPowerStatusEx.asp
> 
> and:
> 
> http://msdn.microsoft.com/library/en-us/wceshellui5/html/wce50lrfsystempowerstatusex.asp
> 
> -Kevin
> 
> 
> 2006-12-02  Kevin O'Connor  <kevin@...>
> 
>         * include/winbase.h: Add SYSTEM_POWER_STATUS_EX structure.
>           Add GetSystemPowerStatusEx function definition.
> 
--

-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT

Re: ARM macro definition

Danny Backx escreveu:
> Pedro,
>
> The commit described below moves the _M_ARM definitions from gcc
> internals into an include file.
>
> For the _M_ARM, this is clearly something that needed to be done : its
> value depends on it, you cannot do this easily in the gcc internals.
>
> I am wondering why we would need to do this for the ARM macro though.
>
> The downside of this is that some sources need to either include winnt.h
> or implement the same processing, none of which seems necessary.
>
> My feeling is to move the definition of ARM back into the gcc config,
> but maybe I'm missing something ?
>
>   

Here is the patch that moves _M_ARM and ARM back into gcc builtins, and 
adds _M_ARMT.
_M_ARM and _M_ARMT will be defined to the arm arch being compiled to, 
_M_ARMT will only be defined
if the arm arch supports thumb, and ARM will be defined as empty. I 
think this matches MSFT's tools behavior.

I've tested it manually using -march=armv4, -march=armv5, etc, and with 
-mcpu=arm8, -mcpu=xscale, etc.
I will commit it later if you confirm it works for you, or you can 
commit it yourself if you want.

Re: ARM macro definition

Pedro Alves escreveu:
>
> I've tested it manually using -march=armv4, -march=armv5, etc, and 
> with -mcpu=arm8, -mcpu=xscale, etc.

I meant like this:

$touch test.c
$arm-wince-mingw32ce-gcc -mcpu=xscale  -dD -E test.c | grep ARM

Cheers,
Pedro Alves

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: ARM macro definition

I haven't exactly done stress testing on it but it works for me, thanks.

I've been chasing a bug or two of my own, seem to have found one just
now.

	Danny

On Sun, 2006-12-03 at 13:08 +0000, Pedro Alves wrote:
> Danny Backx escreveu:
> > Pedro,
> >
> > The commit described below moves the _M_ARM definitions from gcc
> > internals into an include file.
> >
> > For the _M_ARM, this is clearly something that needed to be done : its
> > value depends on it, you cannot do this easily in the gcc internals.
> >
> > I am wondering why we would need to do this for the ARM macro though.
> >
> > The downside of this is that some sources need to either include winnt.h
> > or implement the same processing, none of which seems necessary.
> >
> > My feeling is to move the definition of ARM back into the gcc config,
> > but maybe I'm missing something ?
> >
> >   
> 
> Here is the patch that moves _M_ARM and ARM back into gcc builtins, and 
> adds _M_ARMT.
> _M_ARM and _M_ARMT will be defined to the arm arch being compiled to, 

Re: ARM macro definition

I've committed it, as you indicated. That saves you the trouble. Again,
thanks for the work.

	Danny

On Sun, 2006-12-03 at 13:08 +0000, Pedro Alves wrote:
> Here is the patch that moves _M_ARM and ARM back into gcc builtins,
> and 
> adds _M_ARMT.
> _M_ARM and _M_ARMT will be defined to the arm arch being compiled to, 
> _M_ARMT will only be defined
> if the arm arch supports thumb, and ARM will be defined as empty. I 
> think this matches MSFT's tools behavior.
> 
> I've tested it manually using -march=armv4, -march=armv5, etc, and
> with 
> -mcpu=arm8, -mcpu=xscale, etc.
> I will commit it later if you confirm it works for you, or you can 
> commit it yourself if you want.
--

-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________

Progress report

Hi,

Just a quick note to mention that I've been silent because I'm
struggling with stuff such as the -pg option that doesn't always work,
and test coverage tools. I just got the first .gcda file created on my
PDA, but that required build system hacks.

	Danny
--

-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@...
https://lists.sourceforge.net/lists/listinfo/cegcc-devel

proposed patch to install docs

Pedro,

Can I commit this patch, and a similar one for the cegcc script?
One of the issues might be where to install the documentation, another
is where to install the whole toolchain (currently this is what you
wrote in it - /opt/mingw32ce ).

The reason I'm also asking about the installation path is I'd want to
create an RPM based on these scripts. Do we keep the funky path for now
(I used to do the same with my scripts in scripts/linux), or do we move
to a "standard" place.

	Danny
--

-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@...
https://lists.sourceforge.net/lists/listinfo/cegcc-devel

Re: proposed patch to install docs

Danny Backx wrote:
> Pedro,
> 
> Can I commit this patch, and a similar one for the cegcc script?

Ok.

> One of the issues might be where to install the documentation, another
> is where to install the whole toolchain (currently this is what you
> wrote in it - /opt/mingw32ce ).
> 
> The reason I'm also asking about the installation path is I'd want to
> create an RPM based on these scripts. Do we keep the funky path for now
> (I used to do the same with my scripts in scripts/linux), or do we move
> to a "standard" place.
> 

What do you have in mind as a "standard" place?

Cheers,
Pedro Alves

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

Re: proposed patch to install docs

Danny Backx wrote:
> On Mon, 2006-12-18 at 10:23 +0000, Pedro Alves wrote:
> 
>>Danny Backx wrote:
>>
>>>The reason I'm also asking about the installation path is I'd want to
>>>create an RPM based on these scripts. Do we keep the funky path for now
>>>(I used to do the same with my scripts in scripts/linux), or do we move
>>>to a "standard" place.
>>>
>>
>>What do you have in mind as a "standard" place?
> 
> 
> Isn't PREFIX=/usr/local the standard ?
> 
> I can't find an accurate description (but one that comes close is on
> http://www.gnu.org/prep/standards/standards.html#Directory-Variables,
> see below).
> 
> My understanding has always been that system components should
> install with PREFIX=/usr and others (additional software, "local"
> packages) with PREFIX=/usr/local .
> 

cegcc's first releases used to set PREFIX=/usr/local. At the time I was
convinced that was the best place.  I remember Chad J saying it wasn't
nice.  I didn't agree at the time, but now I do. :)  Although his 
complain was about not being easy to remove the toolchain,
since it gets mingled up with other apps, my agreement comes from