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 <[email protected]> 작성: > >> On 2021-05-25, at 08:23, 조성빈 <[email protected]> wrote: >> >>> 2021. 5. 25. 오후 3:56, Andrew Udvare <[email protected]> 작성: >>> >>>> On 2021-05-25, at 02:22, 조성빈 <[email protected]> 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
