Re: Private headers in GSMake frameworks?

[Nicola Pero]

> > > I've found FrameworkName_HEADER_FILES for specifying "Headers", but is
> > > there an equivalent to "PrivateHeaders" in GNUstep-make? What's the
> > > variable called?
> >
> > xxx_HEADER_FILES is for specifying headers which are to be installed and
> > made public.
> >
> > If you have "local" headers which are "private" and are only used when
> > compiling the framework and/or applications/tools internal to the
> > framework, then you just don't list them in xxx_HEADER_FILES and they are
> > not installed, hence not made public.
>
> Yes, I'm familiar with that distinction. However, Apple's
> "PrivateHeaders" is sort of the "protected" (in C++ terms) of the header
> folders. They're intended to be included in the framework, but aren't
> supposed to be used by most clients. For an open-source project like
> GNUstep, this is a very handy distinction.
>
> Take an application like Preferences.app: It has the
> PrefsModule.framework, which contains its PrefsModule protocol. However,
> it may also contain additional classes that are used by Preferences.app,
> which aren't intended for use by people writing PrefsModules, but rather
> are only useful for people writing their own Preferences.app (which is a
> very arcane thing to do).
>
> By placing those headers in "PrivateHeaders" (which is treated by the
> build system just like "Headers"), PrefsModule writers aren't even
> tempted to rely on these headers. However, if a new version of the
> PrefsModule framework comes out, all that's necessary to pick up its
> changes is to recompile Preferences.app against that framework, even if
> the framework is a binary-only distribution.
>
> PrivateHeaders is the place where headers would go that aren't
> guaranteed to stay available in the next revision.
>
> But I guess the answer for now is that there are no PrivateHeaders in
> GNUstep, and that I'll have to put these files in "Headers" and mark
> them as "not for use" some other way.

Thanks for the explanation -- this is nice, but I don't think it should be 
built into the make system given that it's easily (and more flexibly) 
implemented in 'user space'.

For example, say your framework is called 'Framework'.  You can put your 
public headers in

Framework/Header.h

and your private/protected ones in

Framework/Private/Header.h

Then it's obvious that

#include <Framework/Private/Header.h>

is using private/protected headers of the framework, and

#include <Framework/Header.h>

is using a public header.

Of course you might prefer a different naming convention, but the point is 
that all the headers are the same, and you are free to choose / establish 
a naming convention to differentiate which headers are public and which 
are not, by putting them in directories with explanatory names, or maybe 
prefixing/suffixing the private ones with some sort of prefix/suffix ? 
Anyway, from the point of view of the make system, it sounds OK that all 
headers are the same.

Thanks