This is split off from bug 93082. Basically, if there is a header that needs to be fixincluded in /Systems/Library/Frameworks or /Library/Frameworks or ${SDKROOT}/Library/Frameworks, fixincludes currently won't find it. This should be fixed by adding another include tree (or trees) for fixincludes to search.
Mine.
Related: bug 37036
(In reply to Eric Gallager from comment #0) > This is split off from bug 93082. Basically, if there is a header that needs > to be fixincluded in /Systems/Library/Frameworks or /Library/Frameworks or > ${SDKROOT}/Library/Frameworks, fixincludes currently won't find it. This > should be fixed by adding another include tree (or trees) for fixincludes to > search. the way that header search works, you probably want to keep the sysroot (a.k.a SDKROOT) distinct (you might want to look in gcc/config/darwin-c.cc for how the eventual search paths are constructed, just for background). Solving 37036 would also allow us to have multiple SDKs - which would be nice since we can, in principle, target any version of Darwin with the same compiler - the limitation preventing that is that the fixed includes (and SDK includes used in some libraries) do not work over more than a few OS revisions .. forcing us to need cross compilers for other OS versions in a rather artificial way. If we could implement the OS version as a multilib we could avoid that and just have one compiler to target any version (or the same arch, of course). [dreams of things we might do if time were available]
Created attachment 55084 [details] Implement the use of fixed framework headers this was a proof-of-principle exercise while looking into issues caused by implementing __has_feature () [PR60512]. This does not have any of the mechanism to *create* or *install* the fixed headers (for my testing I just built a CoreFoundation.framework/Headers/CFBase.h and edited bye hand to fix the problems found). So, still plenty to do ;)
It's been a long time since I mucked with fixincludes. My first guess, without going back and reading code, would be to provide fixincludes with a list of trees to traverse and not have it burned into fixincludes at all. That might even be helpful for cross compiles also. :)
(In reply to Iain Sandoe from comment #4) > Created attachment 55084 [details] > Implement the use of fixed framework headers > > this was a proof-of-principle exercise while looking into issues caused by > implementing __has_feature () [PR60512]. > > This does not have any of the mechanism to *create* or *install* the fixed > headers (for my testing I just built a > CoreFoundation.framework/Headers/CFBase.h and edited bye hand to fix the > problems found). > > So, still plenty to do ;) Remind me to test this patch later; I've kind of forgotten where I was with this... distracted with other stuff... (maybe I should unassign it from myself?)
(In reply to Eric Gallager from comment #6) > (In reply to Iain Sandoe from comment #4) > > Created attachment 55084 [details] > > Implement the use of fixed framework headers > > > > this was a proof-of-principle exercise while looking into issues caused by > > implementing __has_feature () [PR60512]. > > > > This does not have any of the mechanism to *create* or *install* the fixed > > headers (for my testing I just built a > > CoreFoundation.framework/Headers/CFBase.h and edited bye hand to fix the > > problems found). > > > > So, still plenty to do ;) > > Remind me to test this patch later; I've kind of forgotten where I was with > this... distracted with other stuff... (maybe I should unassign it from > myself?) Unassigning from myself due to being distracted by too many other things; maybe FX would like to take over?