> -----Original Message-----
> From: Jonathan Worthington [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 20, 2004 4:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PATCH] Re: [perl #25239] Platform-specific files not
> granular enough
>
>
[snip]
>
> Creating an empty signal.h works fine, but then I ran into a
> load of errors
> in platform.c. On further inspection, we're coming out with this in
> platform.c:-
>
> --
> #include "parrot/parrot.h"
>
> /*
> ** config/gen/platform/win32/begin.c:
> */
>
> #include <windows.h>
> --
>
> Somewhere in parrot/parrot.h, something causes winsock.h to
> be included. I
> can't for the life of me find *where*, but it is being. The
> problem with
> this is that it's being included before windows.h is being
> included, which
> means stuff that needs to be defined isn't.
>
> I've attached a patch which causes stuff in begin.c to be put
> before the
> #include "parrot/parrot.h" line, which fixes up this problem.
> I don't know
> if it's the right thing to do, but it's the best one I could think of.
> Please create the empty signal.h too - BTW, how should I have
> gone about
> including that in my patch (e.g. what's the flag for cvs diff)?
>
> Thanks,
>
> Jonathan
>
I thought this might come up. For non-specific, must-be-first preprocessor directives
(like #include <windows.h>), your solution is probably just fine. There aren't
terribly many pathological headers like that, so this fix should cover the sane cases.
If a platform comes along that is particularly sensitive to ordering w.r.t. #defines
and #includes, it might be necessary to let it recommend an ordering for the
concatenation relative to each other and #include "parrot/parrot.h".
For example, the extant worrisome case is darwin.c, which used to say:
#include <time.h>
#include <sys/time.h>
#undef environ
#undef bool
#import <mach-o/dyld.h>
#include "parrot/parrot.h"
...
Now it has become:
#include "parrot/parrot.h"
/* in darwin/begin.c */
#undef environ
#undef bool
/* pieces of generic/ */
/* in darwin/dl.c */
#import <mach-o/dyld.h>
...
#include <time.h>
#include <sys/time.h>
Moving the undefs quite possibly could change their effect. If the only intent is for
them to be before dyld.h, no problem. OTOH, perhaps they should be before parrot.h as
well, which Jonathan's patch will accomplish. (Or maybe dyld.h needs to be before
parrot.h, which would require splitting it out of dl.c, yuck.) There doesn't appear
to be a tinderbox with this configuration ATM. Can anyone test this?
Adam
