On Sun, Jul 5, 2020 at 6:15 PM Ken Cunningham < [email protected]> wrote:
> > On Jul 5, 2020, at 3:03 PM, Jason Liu <[email protected]> wrote: > > 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. >> > > 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? > > > > 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. > 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. -- Jason Liu On Sun, Jul 5, 2020 at 6:15 PM Ken Cunningham < [email protected]> wrote: > > > On Jul 5, 2020, at 3:03 PM, Jason Liu <[email protected]> wrote: > > > > Other than using the __MACPORTS_LEGACY_SUPPORT_APPKIT__ macro, is there > some way of making it optional? > > > 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). > > > 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. >> > > 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? > > > > 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. > > We only came up with SnowLeopardFixes -> LegacySupport after literally > hundreds of ports needed the same patches for the same missing functions. > > 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). > > 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. > > Ken >
