[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bundlelisation of the backend
From: |
Frederic De Jaeger |
Subject: |
Re: bundlelisation of the backend |
Date: |
31 Mar 2001 12:43:21 +0200 |
User-agent: |
Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 |
RFM> Generally, I'd try to avoid introducing new files if possible, and I also
RFM> try (very hard) to make sure that things are declared in the same headers
RFM> that MacOS-X uses (to support source-code compatibility).
RFM> In this case, MacOS-X declares the NSWindowDepth typedef in NSGraphics.h
RFM> so I'd try to stick to that.
RFM> Can you organise things so that the file you are including in NSGraphics.h
RFM> does not need to include NSGraphics.h? ie. include it at a point where
RFM> everything it depends on has already been declared?
I try, but it's terrible. The dependency graph is quite complex if
NSWindowDepth is defined in NSGraphics.h, unless I use some tricks like
#define __NSGraphicsContext_h_is_being_parsed_now_so_be_careful
...
#undef __NSGraphicsContext_h_is_being_parsed_now_so_be_careful
RFM> Alternatively, can you move this typedef to the file that is being included
RFM> in NSGraphics.h?
This is the easiest to do. If I move the typedef :
typedef int NSWindowDepth;
from NSGraphics.h to GSMethodTable.h, everything works fine. No more
loops. So if you agree, this is my solution.
RFM> Creating a new file would be my third or fourth choice, fighting
RFM> it out with the nasty hack of putting the typedef in NSGraphics.h
RFM> but outside the ifndef __NSGraphics_h__ (protected by it's own
RFM> bit of preprocessor condition of course)
could be done, too. What do you prefer ?
RFM> _______________________________________________
RFM> Gnustep-dev mailing list
RFM> address@hidden
RFM> http://mail.gnu.org/mailman/listinfo/gnustep-dev