You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by cm...@collab.net on 2001/01/29 21:15:13 UTC
Re: cvs commit: apr/file_io/win32 filestat.c
Hey, all. This fix also fixed a build problem I was having in Win98,
but I'm worried that the fix might be skirting a bigger issue. Code
exists in apr_private.h that "turns off" the use of Windows' GDI
library (by #define'ing NOGDI) among other things. The recent
inclusion of <aclapi.h>, on Win98 platforms, eventually results in
<wtypes.h> being included, part of which depends on the GDI headers
being available. I do NOT expect this to happen on WinNT, but as I
don't have an NT box here, I can't verify that.
At any rate, the REASON the fix below helped is because the GDI stuff
wasn't opted out until the following conclusion of apr_private.h. I
general get concerned when the order of header inclusion means the
difference between a successful and a failed build.
Can someone provide some insight as to why APR explicitly attempts to
bar inclusion of the GDI, USER, and 3 other classes of header files in
apr_private.h?
Thanks.
--Mike
stoddard@apache.org writes:
> stoddard 01/01/29 09:10:22
>
> Modified: file_io/win32 filestat.c
> Log:
> This fixes a funky compile problem for me.
>
> Revision Changes Path
> 1.44 +1 -1 apr/file_io/win32/filestat.c
>
> Index: filestat.c
> ===================================================================
> RCS file: /home/cvs/apr/file_io/win32/filestat.c,v
> retrieving revision 1.43
> retrieving revision 1.44
> diff -u -r1.43 -r1.44
> --- filestat.c 2001/01/29 06:21:40 1.43
> +++ filestat.c 2001/01/29 17:10:19 1.44
> @@ -52,6 +52,7 @@
> * <http://www.apache.org/>.
> */
>
> +#include <aclapi.h>
> #include "apr_private.h"
> #include "win32/fileio.h"
> #include "apr_file_io.h"
> @@ -62,7 +63,6 @@
> #include <sys/stat.h>
> #include "atime.h"
> #include "misc.h"
> -#include <aclapi.h>
>
> static apr_status_t free_localheap(void *heap) {
> LocalFree(heap);
>
>
>
Re: cvs commit: apr/file_io/win32 filestat.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "William A. Rowe, Jr." <wr...@rowe-clan.net>
Sent: Tuesday, January 30, 2001 6:04 PM
> From: "Branko Čibej" <br...@xbc.nu>
> Sent: Tuesday, January 30, 2001 5:20 PM
>
> > Is there anything we need from Win32 that we don't get with the following:
> >
> > #define WIN32_LEAN_AND_MEAN
> > #include <windows.h>
> >
> > This omits all sors of crud, and gives reasonably fast compiles, and
> > sould work on all Win32 platforms. You don't get most UI stuff, but we
> > don't need it anyway.
>
>
> We do that today. And more. The more is what bit us :-(
> I haven't even found my way back to apr/httpd-2.0 since that patch. I'm not
> really looking forward to it, but I will probably hack a better quick fix
> when I finally get there between tommorow and Friday.
I just got there. Since the <wtypes.h> patch only applies to the few files
that actually require it, the impact on total build time is negligable (whew!)
I'd suggest we don't need to spend any further effort on this right now, since
the quick fix doesn't slow us down, and we are all trying to fight with our
individual itches :-)
Bill
Re: cvs commit: apr/file_io/win32 filestat.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Branko Čibej" <br...@xbc.nu>
Sent: Tuesday, January 30, 2001 5:20 PM
> > I'll keep researching the issue over here to see if I can come up with
> > a solid solution. I would ask that if developers have a patch that
> > they think might in some way break the Win98 build they either verify
> > the patch themselves under Win98 or send it to me to validate--I'm
> > cool with that if others are. I'd just like to enjoy the luxury of a
> > buildable APR on a daily basis like others do.
>
> Is there anything we need from Win32 that we don't get with the following:
>
> #define WIN32_LEAN_AND_MEAN
> #include <windows.h>
>
> This omits all sors of crud, and gives reasonably fast compiles, and
> sould work on all Win32 platforms. You don't get most UI stuff, but we
> don't need it anyway.
We do that today. And more. The more is what bit us :-(
We want to eliminate other gobs of stuff. Consider that we will let the
user do whatever they want before we get our hands into the pot (they could
include <windows.h> with any set of restrictions or not before including
any apr headers.) Yes, LEAN_AND_MEAN is better than nothing. NOGDI, NOUSER
and the rest of our list is even better. Compiling many dozens of sources
with no precompiled headers means we want to do our best (for our benefit)
to strip down what we can.
I haven't even found my way back to apr/httpd-2.0 since that patch. I'm not
really looking forward to it, but I will probably hack a better quick fix
when I finally get there between tommorow and Friday.
Bill
Re: cvs commit: apr/file_io/win32 filestat.c
Posted by Branko Čibej <br...@xbc.nu>.
cmpilato@collab.net wrote:
> "William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
>
>> Yuck. I don't seem to have those interactions with vc5.0/SDK 2000.
>> But you are right, we just slowed the build by bypassing these
>> inclusions.
>>
>> We can selectively toggle off -parts- of the GDI without turning it off
>> entirely. Since I can't see which parts are used (we are looking at
>> different wtype.h versions) I can't help too much.
>
>
> I think the fork in the road is the #define __midl that I'm assuming
> (based on comments in <winnt.h>) only gets set in WinNT and higher.
> Since it doesn't get set in Win98 by default, the header inclusion
> stuff takes a different route, if you will. At least, this is my best
> guess at this stage.
>
>> The patch ought to be reverted after we fix apr.hw to toggle off what
>> we can without toggling off anything more. Does this sound like an
>> amusing project for you, Mike?
>
>
> Heh. Amusing? Not any more so than your question. ;-) But if it
> needs to be done, it needs to be done, right?
>
> I'll keep researching the issue over here to see if I can come up with
> a solid solution. I would ask that if developers have a patch that
> they think might in some way break the Win98 build they either verify
> the patch themselves under Win98 or send it to me to validate--I'm
> cool with that if others are. I'd just like to enjoy the luxury of a
> buildable APR on a daily basis like others do.
Is there anything we need from Win32 that we don't get with the following:
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
This omits all sors of crud, and gives reasonably fast compiles, and
sould work on all Win32 platforms. You don't get most UI stuff, but we
don't need it anyway.
--
Brane Čibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: cvs commit: apr/file_io/win32 filestat.c
Posted by cm...@collab.net.
"William A. Rowe, Jr." <wr...@rowe-clan.net> writes:
> Yuck. I don't seem to have those interactions with vc5.0/SDK 2000.
> But you are right, we just slowed the build by bypassing these
> inclusions.
>
> We can selectively toggle off -parts- of the GDI without turning it off
> entirely. Since I can't see which parts are used (we are looking at
> different wtype.h versions) I can't help too much.
I think the fork in the road is the #define __midl that I'm assuming
(based on comments in <winnt.h>) only gets set in WinNT and higher.
Since it doesn't get set in Win98 by default, the header inclusion
stuff takes a different route, if you will. At least, this is my best
guess at this stage.
> The patch ought to be reverted after we fix apr.hw to toggle off what
> we can without toggling off anything more. Does this sound like an
> amusing project for you, Mike?
Heh. Amusing? Not any more so than your question. ;-) But if it
needs to be done, it needs to be done, right?
I'll keep researching the issue over here to see if I can come up with
a solid solution. I would ask that if developers have a patch that
they think might in some way break the Win98 build they either verify
the patch themselves under Win98 or send it to me to validate--I'm
cool with that if others are. I'd just like to enjoy the luxury of a
buildable APR on a daily basis like others do.
Oh, and I want an office with a view. And a company car--SUV, British
racing green, please. And options, gimme options, and...
Re: cvs commit: apr/file_io/win32 filestat.c
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: <cm...@collab.net>
Sent: Monday, January 29, 2001 2:15 PM
>
> Hey, all. This fix also fixed a build problem I was having in Win98,
> but I'm worried that the fix might be skirting a bigger issue. Code
> exists in apr_private.h that "turns off" the use of Windows' GDI
> library (by #define'ing NOGDI) among other things. The recent
> inclusion of <aclapi.h>, on Win98 platforms, eventually results in
> <wtypes.h> being included, part of which depends on the GDI headers
> being available. I do NOT expect this to happen on WinNT, but as I
> don't have an NT box here, I can't verify that.
Yuck. I don't seem to have those interactions with vc5.0/SDK 2000.
But you are right, we just slowed the build by bypassing these
inclusions.
We can selectively toggle off -parts- of the GDI without turning it off
entirely. Since I can't see which parts are used (we are looking at
different wtype.h versions) I can't help too much.
The patch ought to be reverted after we fix apr.hw to toggle off what
we can without toggling off anything more. Does this sound like an
amusing project for you, Mike?
> Can someone provide some insight as to why APR explicitly attempts to
> bar inclusion of the GDI, USER, and 3 other classes of header files in
> apr_private.h?
Because it speeds up the build by 300%? Seriously, if you are using APR to
develop an app that employs the excluded mechanisms, you must include the
Windows.h before you include any apr_.h headers. That is by design.
Before you consider the obvious (precompile through apr.h) consider that it
only works if every module agrees to include the headers, with no cruft,
in the same order. Since we've agreed to disagree on this topic, and include
headers willy nilly in the sources, precompiled headers work for exactly one
source file and can't be applied any other file.
Bill