gnustep-dev
[Top][All Lists]
Advanced

[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: Wed, 09 Jul 2003 13:37:05 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507

Nicola Pero wrote:

Do we all agree then, and can we start changing things ?

Almost, one minor detail, the structure of the Headers in the source tree. Without much thought, I'd simply suggest

base/Headers/GNUstepBase/
base/Headers/gnustep/Foundation/
gui/Headers/GNUstepGUI/
gui/Headers/gnustep/AppKit/

with an extra -I../Headers/gnustep when installing -base and -gui, as opposed to -baseadd (and -guiadd once we have it.)
Changing this would be part of step 3 below.

The tasks seem to be, in the order:

1. make --enable-flattened the default

Yes, this can be done independant of all other changes.

2. put headers into Headers/$LIBRARY_COMBO if not flattened

I'm not sure what you mean. Are you talking about a convenience* *script that relocates the installed headers to make them work with the new infrastructure without having to reinstall them? Good idea! Would it be executed as part of installing -make? But please don't commit it, until I'm ready to commit step 3.

3. change gnustep-base and gnustep-gui to install headers into
   {header dir chosen by gnustep-make}/Foundation/
   {header dir chosen by gnustep-make}/GNUstepBase/
   {header dir chosen by gnustep-make}/AppKit/
   {header dir chosen by gnustep-make}/GNUstepGUI/
4. remove -Ixxx/Headers/gnustep from gnustep-make

Maybe this should be postponed one release cycle of the core packages for transitioning, I still mean to create those dummy headers here.


5. update all GNUstep libraries' #includes for the change.

I suppose I could do the gnustep-make changes (1, 2, 4) and David could do the library changes (3, 5).


Together with point 3, I'll also update -back as that should be done more ore less simultaniously to keep the core packages in sync.

The rest can be done in a second step, yet I would like the OK from the maintainers of the other projects before before proceeding with the update of those, just in case someone is about to prepare a release based on the last "stable" releases of the core libraries.

Renaissance (Nicola ?)
StepTalk (doesn't seem to be affected)
db (save objections, I'll update this)
extensions (save objections, I'll update this)
gdl2 (Manuel?, as we don't have releases yet, I think this should be ok to update)
gsantlr (Manuel?)
gscrypt (doesn't seem to be affected)
gsgd (doesn't seem to be affected)
gsldap (Manuel?)
gsweb (Manuel?)
guile (doesn't seem to be affected)
java (save objections, I'll update this)
ruby (doesn't seem to be affected)
ucsdata (doesn't seem to be affected)

and apps:
EasyDiff (doesn't seem to be affected)
Gorm (Gregory ?)
ProjectCenter (doesn't seem to be affected)
charsets (doesn't seem to be affected)
libobjc (doesn't seem to be affected)
model-main (doesn't seem to be affected)
nfmake (doesn't seem to be affected)
test (doesn't seem to be affected)

from the examples, only the following appear to be affected, so I'll update them also.
examples/gui/Classes
examples/gui/CurrencyConverter
examples/gui/Finger
examples/gui/GFractal
examples/gui/GSTest

Cheers,
David






reply via email to

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