Re: Framework support for darwin

[Neil Booth <neil at daikokuya dot co dot uk>]

First, is there any chance of Apple people marking their attachments
as text/plain when they are, rather than Octet-stream?  It makes
it hard to reply with the patch inline (and also means my mailer at
least doesn't show the patch inline).  It may be a mime issue at my
end; I'm no mime expert, if so let me know.

Mike Stump wrote:-

> I've cleaned up support for Frameworks on darwin, and include the patch 
> below for further comments.  It isn't quite done, as it needs a 
> ChangeLog, but since people may want code moved around a bit before the 
> dust settles doing them up is almost pointless.

OK, thanks.

> It needs to reviewed by the cppfiles.c people for cleanliness.  
> Roughly, we add two concepts for cpp, one is a callback to synthesize 
> up filenames given a base directory and a file (construct), and the 
> other is a context dependent header lookup mechanism 
> (context_dependent_header).  The code should be clean and not violate 
> the rules, but, let me know if I missed anything.  Docs are missing, 
> let's first figure out if this is the right approach you would like to 
> see, after the dust settles on the implementation, I can do up more 
> docs if you'd like for cpplib.  The only other issue is that construct 
> would need to be initialized to 0 by other users of cpplib.  I don't 
> see a good way around this, and I'm not sure if I need to.

I don't think that's an issue.

> The patch for the C frontend code (shared by all C style languages) 
> adds the general capability for frameworks directly to the frontend and 
> allows ports to add system framework search paths, if their system has 
> such directories.  On darwin we do.
> On systems that don't have such things, and when -F isn't used, we 
> carefully avoid using either callback, so as to not impact speed or 
> semantics.  We also add a flag, -F to support naming new framework 
> directories by the user.

Could you clarify what a framework and a subframework is exactly?
 
> It might have been nice to put all the C frontend code into port files, 
> but, I didn't see a nice way to get -F in there without it, and 
> existing code uses -F, so changing it isn't much of an option, plus, by 
> having it in there this way, we prevent anyone else from absconding 
> with our option, which would be unfortunate.  It might be possible to 
> put all this into the port file, but, it would require oodles of 
> callback code, and some of it, like FRAMEWORK and FRAMEWORK_SYSTEM are 
> non-obvious to me.  If people don't want it in the C frontend, then the 
> questions are, how can we reserved -F to not be used, and is there a 
> way to organize the chain code that so that the changes to the C 
> frontend are nice?

I think putting at least some of it in c-incpath.c is fine.

I have a few minor style issues with the code, but like you say let's
get back to that after agreeing the rest.  There also seem to be
some hard-coded Apple-specific (?) strings like "Frameworks/" etc.,
but let's come back to that too.

It seems that the abstraction you've added to cppfiles.c is

1) A callback that gives the client a chance to return a new file name
   in the case that normal lookup doesn't find one.  There may be a
   better name than context_dependent_header for this.  I don't have
   any objection to this; it is clean and seems quite reasonable
   and doesn't cost non-users.

2) A per-directory optional override to the normal semantics of
   sticking the file name on the end of the directory name.  Again
   I don't have any objection to this either, for much the same reason.

However, without digging too deeply I would have thought that the
callbacks for these could be in darwin-specific code, unless there is
a general need for them (which there apparently isn't!).  I suspect that
one or two target hooks would do.  That would alleviate my concerns about
hard-coded strings etc. too.

I'd like to hear others' thoughts, particularly Zack's.

Neil.