Re: Framework support for darwin

[Mike Stump <mrs at apple dot com>]

On Friday, January 23, 2004, at 02:07 PM, Geoff Keating wrote:
> It seemed inconsistent to have add_path take a CHAIN parameter, but
> then to have separate functions for adding a cpp_dir.  Could you not
> just have one add_cpp_dir_path function that takes a CHAIN parameter
> too?

Yes, done.

> + #ifdef TARGET_OPTION_INIT
> +   TARGET_OPTION_INIT;
> + #endif
>
> So far as I can tell, the only purpose of this macro is to let you
> have some functions in darwin-c.c and some in darwin.c.

Nope.  That's not actually why it exists.  The reason is much more 
obscure.  fix-header.c wants to include parts of the compiler, but not 
all the compiler...  and this ad-hoc inclusion doesn't work for target 
hooks and someone else wanted these things to be target hooks and so, 
we are left with what you see in the patch.

If fix-header wants to include rs6000.o and everything that pulls in, 
and so on... we could go that direction, but, that path isn't the way 
I'd want to go, as that'd probably break something, that then people 
would be unhappy with the patch...  and much unhappiness would result.

I've tried to come up with various other ways to do this and all of 
them failed or were substantially riskier or just plain worse.  :-(

Let me know how you'd like proceed.

> +   for (b = cpp_get_buffer (pfile);
> +        b && cpp_get_file (b) && cpp_get_path (cpp_get_file (b));
> +        b = cpp_get_prev (b))
>
> I would suggest moving more of the logic of this routine into
> cppfiles.c, perhaps having a for_each_stacked_file routine or similar
> that takes a procedure parameter.

Gosh, previously you said:

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

?  Hum, the code started out in that file, you asked for it to be moved 
to darwin.c.  Also, to quote Neil:

> Yuk!  This is nasty.

So, I don't want to move it to his file, unless he wants it there.  
He's previously signed off on his bits...  Since we aren't doing this 
as a general feature, confining the `nasty' bits to darwin.[ch] seems 
reasonable.

Let me know what you and Neil want and I'll do it.

> The new routine should actually look at the include stack, not at side 
> effects of being on the include stack.

Nice idea, but that stack doesn't have the information we'd need for 
processing, so we'd have to map back into the other information anyway 
and even then, we'd need to reprocess it extensively to do this.  If we 
added the information that we need to the include stack, we might be 
able to do it, but that seems more invasive.

Let me know if you want to me add all the information to that stack and 
if you want this done all the time or through a target call back.

> Also, the functions this calls are not documented, and they should be
> since they're part of the interface of cpplib.  The new routine should
> be documented.
>
> +     if ((n=find_subframework_file (fname, cpp_get_path (cpp_get_file 
> (b)))) != 0)
>
> Is this supposed to be '=='?

No.

>   If not, please make it its own statement.

Done.

> !     -D__APPLE_CC__=666"
>
> Well, OK, so we decided we need to define it, now why 666?

666 is as good as any other number.

> A biblical reference?

Yes.

>   Needs a comment saying why this number.

I've updated it to be a 1.

> I think it would be helpful to document how frameworks work in GCC
> here.  There is doubt as to exactly how they should work, but we can
> at least document how they *do* work.  The documentation should be
> detailed enough to be able to answer the question "If I have passed
> this -F option, and the directory it refers to looks like this, and I
> write this #include directive, which file (if any) does it find?"

Done.  Let me know...

Attachment: frameworki.diffs.txt
Description: Text document