[Top][All Lists]

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

Re: Private headers in GSMake frameworks?

From: Nicola Pero
Subject: Re: Private headers in GSMake frameworks?
Date: Sat, 30 Oct 2004 17:56:19 +0100 (BST)

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 It has the
PrefsModule.framework, which contains its PrefsModule protocol. However,
it may also contain additional classes that are used by,
which aren't intended for use by people writing PrefsModules, but rather
are only useful for people writing their own (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 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


and your private/protected ones in


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.


reply via email to

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