Question about `platforms` and `${os.platform}`

Chris Jones jonesc at hep.phy.cam.ac.uk
Sun Dec 12 18:57:19 UTC 2021



> On 12 Dec 2021, at 6:51 pm, Jason Liu <jasonliu at umich.edu> wrote:
> 
> 
>> On Sun, Dec 12, 2021 at 3:03 AM Joshua Root <jmr at macports.org> wrote:
>>> On 2021-12-12 11:54 , Jason Liu wrote:
>>> On Sat, Dec 11, 2021 at 6:41 PM Chris Jones <jonesc at hep.phy.cam.ac.uk 
>>> <mailto:jonesc at hep.phy.cam.ac.uk>> wrote:
>>>> 
>>>>     No, because that would render the port non functional on non darwin
>>>>     OSes. You should only specify the darwin platform when it is
>>>>     actually required, e.g. when then making a os.major conditional that
>>>>     inly makes sense in darwin platforms.
>>> 
>>> 
>>> Wait a minute, didn't Ryan say that "We don't really expect many ports 
>>> to be installable on other operating systems or for maintainers to test 
>>> anything on other operating systems"? So we /should/ worry about the 
>>> port being non-functional on non-Darwin OSes? I'm confused now....
>> 
>> Ports need to be "functional" on non-darwin platforms to the extent that 
>> things like portindex, 'port mirror', and 'port info' work. They don't 
>> need to be actually installable.
> 
> 
> Ah, so it seems like you're saying that the metadata-related stuff that we typically place near the top of the portfiles (e.g. name, version, categories, description, etc.) should all still be "functional" outside of any sort of specific platform context (and thus shouldn't be wrapped inside of a `platform darwin {`), but that it would be alright to wrap the stuff related to the build phases (i.e. fetch, extract, patch, configure, build, destroot, etc.) inside of a `platform darwin {` to hide it from other platforms, because the build phases only relate to the "installable" part? Am I getting that right? Or am I still confused?

The guidelines you should aim to follow are exactly what they have been so far. Ports should be ‘as functional as possible’ on all platforms, so you should aim to place only what you have to inside a darwin platform check. So no, blanket placing everything you mention above inside a darwin check, when there is no technical reason to do so,  is not really what we want. 

> 
> -- 
> Jason Liu
> 
> 
>> On Sun, Dec 12, 2021 at 3:03 AM Joshua Root <jmr at macports.org> wrote:
>> On 2021-12-12 11:54 , Jason Liu wrote:
>> > On Sat, Dec 11, 2021 at 6:41 PM Chris Jones <jonesc at hep.phy.cam.ac.uk 
>> > <mailto:jonesc at hep.phy.cam.ac.uk>> wrote:
>> > 
>> >     No, because that would render the port non functional on non darwin
>> >     OSes. You should only specify the darwin platform when it is
>> >     actually required, e.g. when then making a os.major conditional that
>> >     inly makes sense in darwin platforms.
>> > 
>> > 
>> > Wait a minute, didn't Ryan say that "We don't really expect many ports 
>> > to be installable on other operating systems or for maintainers to test 
>> > anything on other operating systems"? So we /should/ worry about the 
>> > port being non-functional on non-Darwin OSes? I'm confused now....
>> 
>> Ports need to be "functional" on non-darwin platforms to the extent that 
>> things like portindex, 'port mirror', and 'port info' work. They don't 
>> need to be actually installable.
>> 
>> > That's why I originally thought that `platforms darwin` implied that the 
>> > portfile was only intended to be valid on Darwin. Now that I've learned 
>> > that `platforms darwin` doesn't actually do anything, I'm just... confused.
>> 
>> It means the port is expected to only be installable on darwin. Ports 
>> need to be more or less "valid" anywhere. The platforms option "doesn't 
>> actually do anything" in precisely the same way that statement is true 
>> for the description, i.e. what it does is simply make that information 
>> known to users.
>> 
>> - Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20211212/d8c13ea9/attachment.htm>


More information about the macports-dev mailing list