Some questions regarding MacPorts legacy support package

[Jason Liu]

On Sun, Jul 5, 2020 at 6:15 PM Ken Cunningham <
ken.cunningham.webuse at gmail.com> wrote:

>
> On Jul 5, 2020, at 3:03 PM, Jason Liu <jasonliu at umich.edu> 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 <
ken.cunningham.webuse at gmail.com> wrote:

>
>
> On Jul 5, 2020, at 3:03 PM, Jason Liu <jasonliu at umich.edu> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200706/e31e0535/attachment.htm>