Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-ID: <950C9B37DD02D3118CB600C0F0483545D6E0@mailgate.hampton.co.uk>
From: Andrew Younger <ayounger AT hampton DOT co DOT uk>
To: "'Larry Hall (RFK Partners, Inc)'" <lhall AT rfk DOT com>
Cc: "'cygwin AT sourceware DOT cygnus DOT com'" <cygwin AT sourceware DOT cygnus DOT com>
Subject: RE: windows.h breaks ObjC ?
Date: Mon, 29 Nov 1999 09:18:02 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"

Can you not just code fix it ala this,

#include <windows.h>
#undef interface
#include <objc/Object.h>
int main ( int argc, char *argv[] (
{
  printf("hello world\n");
  return 0;
}

If this works, then you could of course do it nicer, by seperating the
#undef's into a seperate file you include after <windows.h>, or you could
make a mywindows.h or equivalent which includes windows.h & the undefs, you
then of course would include this as opposed to windows.h.

This solution would probably be the best as it means that if the problem
re-occurs later on then you only have to modify one file to fix it.

> -----Original Message-----
> From: cygwin-owner AT sourceware DOT cygnus DOT com
> [mailto:cygwin-owner AT sourceware DOT cygnus DOT com]On Behalf Of Larry 
> Hall (RFK
> Partners, Inc)
> Sent: Monday, November 29, 1999 3:55 AM
> To: mlx AT san DOT rr DOT com
> Cc: cygwin AT sourceware DOT cygnus DOT com
> Subject: Re: windows.h breaks ObjC ?
> 
> 
> At 06:26 PM 11/28/99 -0800, MarketLogix wrote:
> >
> >
> >Begin forwarded message:
> >
> >X-Sender: lhall AT pop DOT ma DOT ultranet DOT com
> >X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
> >Date: Sun, 28 Nov 1999 18:30:22 -0500
> >To: mlx AT san DOT rr DOT com
> >From: "Larry Hall (RFK Partners, Inc)" <lhall AT rfk DOT com>
> >Subject: Re: windows.h breaks ObjC ?
> >Cc: "cygwin AT sourceware DOT cygnus DOT com" <cygwin AT hotpop DOT com>
> >In-Reply-To: <9911281643 DOT AA07798 AT mlx DOT com>
> >
> >At 08:43 AM 11/28/99 -0800, you wrote:
> >>Hi all,
> >>
> >>Just installed v1.0 and spent the whole weekend pulling my hair out.
> >>
> >>Oh, the general product looks pretty nice but I'm afraid 
> that the new
> >>windows headers somehow break ObjC preprocessing.  I know 
> that Cygnus
> >>has never supported ObjC so, as usual, I didn't expect much.
> >>
> >>But it seems as though we may have hit a new low here.
> >>
> >>Either that or I'm just too bleary-eyed to see something obvious.
> >>
> >>Take this source code example, lets call it -> test.c
> >>
> >>#include <windows.h>
> >>#include <objc/Object.h>
> >>int main ( int argc, char *argv[] (
> >>{
> >>  printf("hello world\n");
> >>  return 0;
> >>}
> >>
> >>now try to compile it to object via:
> >>
> >>gcc -c -x objective-c test.c -o test.o
> >>
> >>I get the foillowing:
> >>
> >>Object.h:37: invalid identifier `@struct'
> >>Object.h:37: parse error before `Object'
> >>Object.h:38: syntax error before `{'
> >>Object.h:43: method definition not in class context
> >>
> >>This is, of course, the first occurence of an
> >>
> >>@interface directive
> >>
> >>Now, comment out
> >>//#include <windows.h>
> >>
> >>it compiles without a hitch.
> >>
> >>I built gcc-2.95.2 from gnu AND download pre-built from
> >>Mumit Khan's site ALL with the same result.
> >>
> >>Gotta roll back to b20.1 ?
> >>
> >>What gives ?
> >>
> >>------------
> >>
> >>Well, I didn't send this mail right away and decided to research
> >>a bit more.  Here's what I found:
> >>
> >>basetyps.h, line #20: #define interface struct
> >>
> >>Oh, just brilliant - concocted by some C++ 'er no doubt !!!
> >>C'mon, please tell me you're not already married to this.
> >>
> >>Steve B.
> >>
> >
> >I think you'll find this is a MSism for COM.  I'm sure you can work  
> >around
> >this if necessary but if not, perhaps you want to take it up 
> with MS...
> >
> >
> >Larry Hall                              lhall AT rfk DOT com
> >RFK Partners, Inc.                      http://www.rfk.com
> >118 Washington Street                   (508) 893-9779 - RFK Office
> >Holliston, MA 01746                     (508) 893-9889 - FAX
> >                                        (508) 560-1285 - cell phone
> >
> >
> >Hmmmm ...
> >You're the second individual to blame M$ here.
> >I'm no big fan of those guys either.  But I think
> >this line of reasoning is flawed enough to take the
> >time to slooooowly and cleeeeearly state what I
> >believe to be the real underlying problem.
> >
> >1. I understand that M$ has its need of the "interface" label.
> >
> >2. This is NOT the problem.
> >
> >3. "interface" is distinct from "@interface".
> >
> >4. No problem with the global name space yet.
> >
> >Right ?
> >
> >5. Now all of a sudden in the new Cygnus windows api headers
> >   we get this bad boy:
> >
> >#define interface struct
> >
> >Sure, and while we're at it why not:
> >
> >#define constructor tulips
> >
> >and
> >
> >#define class urass
> >
> >What the heck nobody really codes in ObjC anymore anyway right ?
> >Ah, they didn't create #undef for nothing ... RIGHT ?
> >
> >Yea sure, I can unhack this hack but I would hope folks could
> >think a bit deeper and see this "little inconvenience" for what
> >it really is.
> >
> >The first baby steps toward breaking Objective-C compatibility
> >within Cygwin sources.
> >
> >Steve B.
> >
> 
> Steve,
> 
> Interesting that you feel so strongly that MS is not the 
> source of your
> problem and Cygwin is.   You are free to your interpretation and your 
> opinions and you're not bound to make use of any information you may 
> receive on this list.  However, I fail to see the logic of 
> your resistance
> to the information I and others have provided, especially 
> given that you
> "take the time to slooooowly and cleeeeearly state what <you> 
> believe to be 
> the real underlying problem."  If you're going to spend the 
> time to (re)state
> your problem, its wise to consider it carefully in light of 
> information 
> provided.  Reviewing your statements, I find that you claim 
> "interface" is 
> different from "@interface" (3), that MS needs the 
> "interface" label (1), 
> and that MS's need of this label is not the cause of your 
> problem (2).  
> Let's assume these are all true.  Then you state that Cygwin 
> added "#define 
> interface struct" to its "windows api headers" (5).  OK, so 
> if I'm supposed 
> to believe (1), (2), and (3), then why is (5) a problem?  You said 
> "interface" and "@interface" are not the same things.  If 
> they aren't, then
> "this bad boy" that was added is of no consequence.  So both 
> statements 
> can't be true and, as it turns out, for the purposes of code and cpp, 
> statement (3) is flawed.  "interface" and "@interface" will 
> both get the 
> "interface" portion mapped to "struct".  Clearly, that's your 
> problem (which 
> I understood quite clearly when I answered your first email 
> message by the
> way).  So, this only leaves the issue of whether it makes 
> sense to have 
> "#define interface struct" in the Cygwin version of the 
> Windows header files.  
> 
> You claim in your original email message that this statement 
> is in the 
> Cygwin basetyps.h file.  I'll take your word on that since I 
> don't have 
> the Cygwin V1.0 or gcc-2.95.2 at the moment.  I checked my VC++ 6.x 
> installation, however, and found a file called BASETYPS.H with exactly
> the same #define:
> 
> BASETYPS.H:#define interface struct
> 
> Now, I'm not going to tell you that the existence of this 
> same-named file
> in Cygwin with the same #define means there is no issue with 
> the Cygwin
> version.  I can't verify that things in the Cygwin version 
> are done exactly
> the same way as the MS version without having both and doing the diff 
> myself.  However, what I can say is the #define IS the source of your 
> problem and its existence is NOT simply an ill-conceived whim 
> on someone's
> part.  The MS file has it.  That's why it was added to 
> Cygwin.  If it's 
> addition generates problems/bugs, no one will have a problem 
> if you care
> to track it down and submit a patch for the problem you see.  
> If, however,
> you find that there is no difference between what Cygwin has 
> and what MS does
> for VC++ in this matter, you may find you have no choice but 
> to work-around
> the issue.  I can't and won't predict what the outcome will 
> be if you care 
> to track your issue to its logical conclusion.  I can predict 
> that your 
> somewhat less-than-appreciative email persona (at least on 
> this issue) will
> not likely garner many concerned and helpful responses.  Just 
> a guess...
> 
> Anyway, good luck with your problem.  Hopefully you'll find 
> something in 
> what I said above helpful.
> 
> 
> 
> 
> Larry
> 
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
> 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com