<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">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 style="overflow-wrap: break-word;"><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" class="gmail_signature" data-smartmail="gmail_signature"><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">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 style="overflow-wrap: break-word;"><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>