Different versions per swift version in Portfile

[조성빈]

Thanks for your help! I opened #11143 <https://github.com/macports/macports-ports/pull/11143> based on your suggestions.

> 2021. 5. 25. 오후 9:34, Andrew Udvare <audvare at gmail.com> 작성:
> 
>> On 2021-05-25, at 08:23, 조성빈 <goranmoomin at daum.net> wrote:
>> 
>>> 2021. 5. 25. 오후 3:56, Andrew Udvare <audvare at gmail.com> 작성:
>>> 
>>>> On 2021-05-25, at 02:22, 조성빈 <goranmoomin at daum.net> wrote:
>>>> 
>>>> Thanks for the helpful advice!
>>>> 
>>>> I’ve incorporated some changes from your suggestions, e.g. adding subports.
>>>> However I’m not sure if I’m writing idiomatic port files…
>>>> Could you skim my portfile attached and check if there’s any glaring mistakes?  
>>>> 
>>>> I’m guessing I should also have a swift-format54 subport.
>>>> Is there any way to do something like aliasing the main port to a specific subport?
>>>> It doesn’t feel right to have logic for Swift 5.4 outside the swift-format54 subport body…
>>> 
>>> I don't know if there's a way to alias, but normally the top level gets no suffix and it usually is latest. You could also make it the -devel release (latest Git HEAD), and have swift-format54 subport be the latest stable.
>>> 
>>>> Should I also be checking the maximum version?
>>>> E.g., AFAIK swift-format53 won’t work with Xcode 12.5 or later, should I check this too?
>>> 
>>> Yes. Also you should add "known_fail yes" in that block. Similar to this: https://github.com/macports/macports-ports/blob/d275a24edbefe7f361f2aa6eb8f59648092058c0/graphics/Paintbrush/Portfile#L29
>> 
>> Ok, thanks.
>> In fact, I just searched for known_fail and it looks like the following ui_error and return -code are enclosed in a pre-fetch block.
>> What is the purpose of the block? Should I be adding pre-fetch to my file?
> 
> They do not have to be in pre-fetch block.
> 
> The pre-fetch block is code to run prior to the fetch phase. post-fetch runs after fetching. Most of the time you don't want to make your own fetch phase. All phases (patch, configure, build, etc) have pre- and post- versions.
> 
>> (Unfortunately searching for it in the MacPorts docs didn’t reveal anything…)
>> 
>> Also, are there any resources for me to find about constructs that I don’t know?
>> The only resource I know is https://guide.macports.org but it doesn’t seem like a canonical source.
> 
> Unfortunately the guide is the main documentation but it is out of date. Anything else has to be learned from existing ports and from reading the comments in the PortGroups. https://github.com/macports/macports-ports/tree/master/_resources/port1.0/group
> 
> I recommend keeping a copy of the main ports and installing the_silver_searcher (provides "ag" command) to quickly search for examples. "ag query"
>> 
>>> A minor issue is that the build phase pulls in other dependencies via Git (which by the way does not add a "depends_build-append port:git" because Xcode comes with Git). You could have MacPorts handle these as separate packages (which is going to be very difficult) or you could pull in the repositories as part of the fetch (or similar) phase in MacPorts. I do this often with projects that use submodules.
>> 
>> Is this also just a minor issue (that isn’t encouraged, but not a blocker), or something that MacPorts would like to avoid?
>> (I guess this question is also something that would be answered if I just submitted the PR, but I’m curious now :-))
> 
> Yes it definitely is preferred to avoid doing network activity outside of the fetch phase. The reason is because someone may have an offline system (and must use source rather than a pre-compiled tgz) where copying the distfiles over would not be enough, so the build would fail.
> 
> It is not a blocker, as there are other ports in the tree that do it too. This is usually because the work to unwrap the downloading from the build phase is very difficult, and users have not filed tickets about it.
> 
> --
> Andrew

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20210526/24495fc1/attachment.htm>