> 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
