Changing port group default options

Rainer Müller raimue at macports.org
Tue Mar 31 08:12:20 PDT 2015


Hello,

I'm late to reply to this, but I want to discuss port group updates like
this one in general.

On 2015-03-18 23:28, MacPorts wrote:
> #47197: cmake-based ports: add cmake.out_of_source yes/no
> -------------------------+-------------------------------------------------
>  Reporter:  mojca@…      |      Owner:  macports-tickets@…
>      Type:  enhancement  |     Status:  new
>  Priority:  Normal       |  Milestone:
> Component:  ports        |    Version:
>  Keywords:               |       Port:  Bear Cockatrice FreeRDP Io

[...]

> -------------------------+-------------------------------------------------
>  Following #33259 and r134128 it would be nice if maintainers of ports
>  using the cmake PortGroup would add the following line to their ports
>  {{{
>  cmake.out_of_source yes
>  }}}
>  and test whether the ports still compile fine (no need for a revbump).
>  Some ports already use out-of-source builds, so those ports would need a
>  minor clean-up.
> 
>  If the port doesn't work that way, please add an explicit
>  {{{
>  cmake.out_of_source no
>  }}}
>  with a short comment (and possibly file an upstream bug report).
> 
>  Once all the ports are tested, this would become the default behaviour and
>  the line (setting `yes`) will be removed from the ports.

In my opinion, changes to the default behavior of port group options
should be introduced with an increment of the port group version.

In this case, it would have worked like this:

1. Add a new port group cmake-1.1.tcl with
   'default cmake.out_of_source yes'
2. Update Portfiles to use 'PortGroup cmake 1.1', test build, and add
   'cmake.out_of_source no' if required

This way, we would not have to touch all Portfiles a second time to
remove the default option.

Futhermore, while we can fix all the Portfiles in the official tree by
search and replace, we do not know whether others keep private port
trees affected by such changes. This is only a minor advantage though
and should not stop us from making changes to port groups.

Rainer


More information about the macports-dev mailing list