Different versions per swift version in Portfile

[조성빈]

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?  

> 2021. 5. 25. 오전 4:15, Andrew Udvare <audvare at gmail.com> 작성:
> 
> 
>> On 2021-05-24, at 13:27, 조성빈 <goranmoomin at daum.net> wrote:
>> 
>> I’m trying to write my first Portfile for the swift-format tool.
>> 
>> I’m referencing the xcodes port as an example of a Swift port.
>> 
>> The problem here is that the version of the tool must be synced with the local swift version.
>> For example, release 0.50400.0 is compatible with Swift 5.4, 0.50300.0 is compatible with Swift 5.3, etc…
>> 
>> My questions:
>> 	• Is it right to give if conditions on the swift version to differentiate versions?
> 
> You probably want to do this by having subports or having separate ports for each version. Subports are easier to maintain as its in one file and can share and inherit variables from a top level. In each subport, change the version and distfile being pulled in. Example, with GitHub PortGroup:
> 
> # Latest version gets no suffix
> github.setup apple swift-format 0.50400.0
> 
> subport ${name}52 {  # name swift-format
>  github.setup apple swift-format 0.50200.1
> }

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…

>> Would executing different version statements on every if branch be sufficient?
> 
> Generally ports don't try to make install-time assumptions on behalf of the user. The user has to pick the correct version to install. This is especially because none of the port's configure, build, etc phases will execute when the packaged is installed via a pre-built tarball.
> 
> Subport use in the kubectl port: https://github.com/macports/macports-ports/blob/c382ef7da2db4cef7a087edbf0d75647f4c708aa/sysutils/kubectl/Portfile#L24
> 
>> 	• If 1. is correct, is there a variable for me to test with?
> 
> You could test with $xcodeversion prior to building/installation. For example in a swift-format53 (where 53 indicates Swift 5.3 compatibility requiring Xcode 12) port:
> 
> subport ${name}53 {  # name swift-format
>  if {[vercmp $xcodeversion 12] < 0} {
>    ui_error "${name} @${version} Xcode 12 or later."
>    return -code error "incompatible Xcode version"
>  }
> }

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?

>> 	• If 1. is incorrect, how should I provide different versions? Would just providing the version only for the latest swift the right choice?
> 
> This would probably be acceptable to most users of Swift. Most users want to stay up-to-date with it. Having the flexibility there for those supporting older platforms would still be appreciated.

Would not supporting older platforms, e.g. supporting only the latest version of Swift make it a blocker to adding this to the main repo? The attached file Portfile.bkup was the one I was originally using without the subports…

> -- 
> Andrew

Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Portfile
Type: application/octet-stream
Size: 2006 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20210525/ad9f5d5f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Portfile.bkup
Type: application/octet-stream
Size: 1108 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20210525/ad9f5d5f/attachment-0001.obj>
-------------- next part --------------