gnustep-dev
[Top][All Lists]
Advanced

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

Re: [RFC] Header organization


From: Alexander Malmberg
Subject: Re: [RFC] Header organization
Date: Fri, 20 Jun 2003 17:39:38 +0200

David Ayers wrote:
[snip]
> For gui things are a bit messier.  All "library" headers are installed
> into AppKit.  Additinally while installing the Model project, certain
> "library" headers are also copied to gnustep/gui, making these few
> redundant.

There's also a DPSClient/ symlink. It isn't installed, and there are no
references to it anywhere (except old ChangeLog/NEWS entries). Unless
there's some obscure reason to keep this, I think it should just be
removed.

> Now, I would volunteer** to help sort this out, if we can find a
> consensus on how it should be and how we can get there.
> 
> My preferred solution would be to have real gnustep/base and Foundation
> (gnustep/gui and AppKit) directories in the source tree as well as in
> the installed Headers directory.

I agree. The current organization of headers is very messy.

> The gnustep/base (gnustep/gui)
> directory whould contain all GS specific headers and the Foundation
> (AppKit) diectory would contain the OS* specific headers.

Another way of splitting the headers would be to put public headers (ie.
headers intended to be used by apps and tools outside core/) in
{Foundation,AppKit}, and private headers (ie. headers used by other
parts of core/) in gnustep/{base,gui}.

> Of course the includes would have to be adapted accordingly.  But this
> would also break user code which currently includes <AppKit/GS*.h> files.
> 
> Do we accept this API instability?

I think we should. If necessary we could (for the next release) install
headers in the old place that issued a warning and explained how the
file should be included and then included the file from the correct
place.

> Do we accept the loss of CVS history by moving the NS*.h files into a
> new directory?

We wouldn't lose any cvs history, it'd just be a bit more inconvenient
to look at the pre-rename history.

[snip]

- Alexander Malmberg




reply via email to

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