<div dir="ltr"><div dir="ltr"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr"><div dir="ltr" class="gmail_attr">On Sun, Jul 5, 2020 at 6:15 PM Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" target="_blank">ken.cunningham.webuse@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div><blockquote type="cite"><div>On Jul 5, 2020, at 3:03 PM, Jason Liu <<a href="mailto:jasonliu@umich.edu" target="_blank">jasonliu@umich.edu</a>> wrote:</div></blockquote><blockquote type="cite"><div><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>If a year or so sounds long, don’t worry. I wrote up the first version 
of legacysupport as “SnowLeopardFixes” in 2016, and it did not get 
really adopted until several years later, after a great deal of 
discussion. </div></blockquote><div><br></div><div>A year?! If it's going to take it that long to get it incorporated into the legacy support package, then maybe I'm better off just directly adding my header to the 'files/' folder in my Blender and MaterialX ports for now? </div></div></div></blockquote><div><br></div><div><br></div><div>Yes, you should absolutely please do that — right now if you like — as a proof-of-concept. Stick in in files/appkitworkaround, and add something like an "-isystem ${filespath}/appkitworkaround" to your cpp flags, and see how it goes. No harm done there. If there are only one or two ports that need this, this is for sure the way to go at the beginning.</div></div></div></blockquote></div><div dir="ltr" class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">On Sat, Jul 4, 2020 at 8:23 PM Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" target="_blank">ken.cunningham.webuse@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><blockquote type="cite"><pre style="white-space:pre-wrap;background-color:rgb(255,255,255)">Question 3:

As you can see from the attached file, I am currently creating a wrapper
for AppKit.h. However, in the projects that I'm trying to package for
MacPorts, their code usually uses '#include <Cocoa/Cocoa.h>'; and the
system Cocoa.h, in turn, has a '#import <AppKit/AppKit.h>'. Is this going
to be a problem? Is the MacPorts legacy support package able to intervene
and insert its wrapper files even if a project's source code doesn't
directly #include/#import that specific header file, but instead, the
header to be patched is nested somewhere inside a tree/chain of header
#includes?

</pre></blockquote><div><br></div><div>This will be — something new. Nobody actually knows how well this will work.</div><div><br></div></div></blockquote></div></div><div><br></div><div>I have what is potentially some very encouraging news to report on this front. Adding my AppKit wrapper file locally to my Blender port, and using the -isystem compiler flag, it appears that using this method does indeed have the effect of "intervening" when the header file that is to be wrapped occurs in the middle of a nested chain of #includes. I'm not sure whether this success will be the case for all compilers, but at least for my particular port, the wrapper is visible to the clang++-mp-9.0 compiler.<br></div><div><br></div><div>This hopefully provides further evidence that eventually adding the AppKit wrapper to the MacPorts legacy support package will be the correct way to go in the long term.<br></div><div><br></div><div><div dir="ltr"><div dir="ltr"><div>-- </div><div>Jason Liu<br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 6, 2020 at 2:44 PM Jason Liu <<a href="mailto:jasonliu@umich.edu" target="_blank">jasonliu@umich.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr" class="gmail_attr">On Sun, Jul 5, 2020 at 6:15 PM Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" target="_blank">ken.cunningham.webuse@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div><blockquote type="cite"><div>On Jul 5, 2020, at 3:03 PM, Jason Liu <<a href="mailto:jasonliu@umich.edu" target="_blank">jasonliu@umich.edu</a>> wrote:</div><br></blockquote><blockquote type="cite"><div><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>If a year or so sounds long, don’t worry. I wrote up the first version 
of legacysupport as “SnowLeopardFixes” in 2016, and it did not get 
really adopted until several years later, after a great deal of 
discussion. </div></blockquote><div><br></div><div>A year?! If it's going to take it that long to get it incorporated into the legacy support package, then maybe I'm better off just directly adding my header to the 'files/' folder in my Blender and MaterialX ports for now? </div></div></div></blockquote><div><br></div><div><br></div><div>Yes, you should absolutely please do that — right now if you like — as a proof-of-concept. Stick in in files/appkitworkaround, and add something like an "-isystem ${filespath}/appkitworkaround" to your cpp flags, and see how it goes. No harm done there. If there are only one or two ports that need this, this is for sure the way to go at the beginning.</div></div></div></blockquote></div><div dir="ltr"><br></div><div>Okay, then I'll proceed going that route. It sounds like adding the AppKit wrapper to the legacy support package is turning out to be much more of a long-term project than I originally anticipated.<br></div><div dir="ltr"><br clear="all"><div><div dir="ltr"><div dir="ltr"><div>-- </div><div>Jason Liu<br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 5, 2020 at 6:15 PM Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com" target="_blank">ken.cunningham.webuse@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div><br><blockquote type="cite"><div>On Jul 5, 2020, at 3:03 PM, Jason Liu <<a href="mailto:jasonliu@umich.edu" target="_blank">jasonliu@umich.edu</a>> wrote:</div><br></blockquote><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>Other than using the __MACPORTS_LEGACY_SUPPORT_APPKIT__ macro, is there some way of making it optional?</div></div></div></blockquote><div><br></div><div>It will have to be specifically disabled by default, and then turned out optionally with some new legacysupport toggle that I/we invent to turn it on (like the one I added to force legacysupport static linking recently, for example).</div><br><blockquote type="cite"><div><div dir="ltr"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>If a year or so sounds long, don’t worry. I wrote up the first version 
of legacysupport as “SnowLeopardFixes” in 2016, and it did not get 
really adopted until several years later, after a great deal of 
discussion. </div></blockquote><div><br></div><div>A year?! If it's going to take it that long to get it incorporated into the legacy support package, then maybe I'm better off just directly adding my header to the 'files/' folder in my Blender and MaterialX ports for now? </div></div></div></blockquote><div><br></div><div><br></div><div>Yes, you should absolutely please do that — right now if you like — as a proof-of-concept. Stick in in files/appkitworkaround, and add something like an "-isystem ${filespath}/appkitworkaround" to your cpp flags, and see how it goes. No harm done there. If there are only one or two ports that need this, this is for sure the way to go at the beginning.</div><div><br></div><div>We only came up with SnowLeopardFixes -> LegacySupport after literally hundreds of ports needed the same patches for the same missing functions.</div><div><br></div><div>You would be surprised at the way things break so easily with what seems like a simple change in one thing that shouldn’t hurt anything. I recently symlinked one single library to make a broken port build and forgot I did it, and it caused a Tornado of fallout that would have been impossible to believe).</div><div><br></div><div>There are probably hundreds of ports that have their own workarounds in them that will respond the wrong way to this. Or maybe there aren’t. It’s impossible to know.</div><div><br></div><div>Ken</div></div></div></blockquote></div></div>
</blockquote></div></div>