[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Header organization of -base & -gui

From: David Ayers
Subject: Re: [RFC] Header organization of -base & -gui
Date: Thu, 03 Jul 2003 15:43:46 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507

Good spot!  So this is a "user" issue. :-/

Nicola Pero wrote:

Maybe gnustep/base originally was meant to provide that level of
indirection, allowing the gnustep-make system to switch between different
foundation libraries headers according to the library combo by simply
adding/removing -Ixxx/gnustep/base from the command line.
You mean with an extra symlink Foundation pointing to .. ?

I suppose we've got the following solutions:


* put only the Foundation (and AppKit) headers in a library-combo subdir;

Unfortunately, the command line gets bigger on average -

Bummer, I was hoping to reduce these, because I believe the extra -I entries are causing quite a performance hit on the preprocessor with all these directories we allready have to search, for third party projects, that might depend on even more external libs adding even more -I entries. But at least we're won't be getting worse than before.

I now think this scheme (or some variant of this scheme) is what was implemented, and the reason why gnustep/base existed. Using gnustep/ instead of gnu-gnu-gnu/ bounds gnustep-base and gnustep-gui together,
  which prevents library-combos such as gnu-fd-gnu (or apple-gnu-apple)
  from working.  Frankly, that does not seem an important matter as those
  will probably never work anyway, but if we go that route, then maybe
  we should consider simplifying the library combo into gnu-gnu (that is,
  {runtime library}-{base/gui library}) rather than gnu-gnu-gnu (that is,
  {runtime library}-{base library}-{gui library}).

I figured that apple-apple-gnu could be interesting, but I really see no practical value. (Just extra incompatible .gorm files and other NSCoding archives.) But what's with gnu-fd-gnu? Also, if I'm considering GDL2 and GSWeb (if Apple ever releases EOF and WebObjects as ObjC Frameworks again) would have similar issues. On the otherhand that is rather academic in my view. I think reducing the lib-combo is fine.

But while we're at it, what's the real value of apple-gnu? And as gnu-apple is rather unlikely, maybe we should reduce it to just gnu / apple / fd? Or is it necessary to maintain apple-fd and gnu-fd? (These questions aren't meant be rhetorical.)

* the hell with library-combos.  Let's drop them.  :-)  Just joking -
this would simplify things considerably, but it would downgrade a lot the flexibility and power of the system, which doesn't sound like a good idea. People who don't want library-combos can use GNUSTEP_FLATTENED anyway.
Well were almost there ;-) but I think to keep what's left could be worthwhile.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]