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.
>

On Sat, Jul 4, 2020 at 8:23 PM Ken Cunningham <
ken.cunningham.webuse at gmail.com> 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 <jasonliu at umich.edu> wrote:

> 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/20200721/754c31ea/attachment.htm>