Re: Framework support for darwin

[Mike Stump <mrs at apple dot com>]

On Tuesday, August 5, 2003, at 12:25 AM, Geoff Keating wrote:
> Issues that made it hard for me to understand this patch:
>
> - You have defined
>
> + typedef const char *(*context_dependent_cb)(cpp_reader *, const char 
> *, const\
>  char *);
>
> but there doesn't seem to be any explanation of what it is supposed to
> do, what its parameters are, or what it returns.

Sometimes it is wrong to copy the coding style of the existing code...

At the top of find_subframework_file I tried to comment on what these 
were:

+ /* Search for FNAME in sub-frameworks.  pname is the context that we
+    wish to search in.  Return the path the file was found at,
+    otherwise return 0.  */
+
+ static const char*
+ find_subframework_file (cpp_reader *pfile, const char *fname, const 
char *pname)
+ {

Anyway, I've added documentation to the top of the typedef to explain 
it it more detail.

> - You say "Search for HEADER in context dependent way" but you don't
>   explain what "context" might be.

I've increased the documentation on find_context_dependent_file to 
address this in the patch below.

> Things that I did understand, and didn't like:
>
> - You seem to have implemented separate framework and regular
>   directory search paths.

Addressed in the patch below.

> - This patch adds a lot of code to c-incpath.c.  Couldn't it be moved
>   into darwin.c?

Anything is possible.  I can add callbacks for everything and make 
everything go though callbacks, if you prefer.  If we always reserve -F 
code frameworks, then, having the compiler actually do the right 
processing for -F arguments I think is fairly natural.  If the code is 
moved into darwin.c, then -F then isn't a general feature that any 
system can use.  By leaving it in c-*.c, it is a general feature that 
any system can use.  How do others feel on this issue?

Essentially, the feature is to allow grouping of header files into 
globs, called frameworks.  Each packages can then have 0 or more 
frameworks.  Quite a few UNIX style includes already use this sort of 
naming convention, such as net, sys, X11, libraw1394, libdv, lesstif, 
though, they don't make use of the physical separation in the 
filesystem.  A framework include is of the form, <framework/rest...>.  
Physically, in the file system, they are laid out like this:

/directory_of_frameworks/X11.framework/Headers/X11.h

If one puts in tons of sym links, and has a program to manage the sym 
links, one can achieve almost the same thing.

One -F/directory_of_frameworks is all that is required, instead of 
oodles of -Is, and all the packages are nice and separate, without the 
need for sym linking.