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. > On Sat, Jul 4, 2020 at 8:23 PM Ken Cunningham < [email protected]> wrote: > > 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? > > > > This will be — something new. Nobody actually knows how well this will > work. > > 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. 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. -- Jason Liu On Mon, Jul 6, 2020 at 2:44 PM Jason Liu <[email protected]> wrote: > 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 >> >
