[Top][All Lists]
[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