[macports-ports] branch master updated: jack: Fix upgrade path from jack1

Ryan Schmidt ryandesign at macports.org
Sat Apr 7 07:50:34 UTC 2018


On Apr 6, 2018, at 16:26, Clemens Lang wrote:

> Clemens Lang (neverpanic) pushed a commit to branch master
> in repository macports-ports.
> 
> 
> https://github.com/macports/macports-ports/commit/a4e16dbb046d89f9146dbc9408f2bfb96ec73a82
> 
> The following commit(s) were added to refs/heads/master by this push:
> 
>      new a4e16db  jack: Fix upgrade path from jack1
> 
> a4e16db is described below
> 
> 
> commit a4e16dbb046d89f9146dbc9408f2bfb96ec73a82
> 
> Author: Clemens Lang
> AuthorDate: Fri Apr 6 23:26:54 2018 +0200
> 
> 
>     jack: Fix upgrade path from jack1
>     
>     The include order generated by the waf version packaged by jack2 is
>     incorrect, which leads to build failures when upgrading from jack1 to
>     jack2 because the build picks up the old jack headers. To avoid this,
>     add a version of the deactivate hack that will deactivate jack1 right
>     before the build.
>     
>     Since this is an uncommon version of the deactivate hack that runs with
>     dropped privileges, separate privilege elevation is necessary.
>     
>     Closes: https://trac.macports.org/ticket/56241
> 
> ---
>  audio/jack/Portfile | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)


> +# deactivate hack added 2018-04-06
> +pre-configure {
> +    # When upgrading from jack1 to jack2, the build can fail outside of trace
> +    # mode because waf puts the CPPFLAGS at the beginning of the compiler
> +    # command line. This was fixed in waf 1.9.0, but jack2 ships waf 1.8.17.
> +    #
> +    # Instead of using the conflicts-build portgroup, use a deactivate hack to
> +    # force-deactive the old version before building, which should solve the
> +    # issue.
> 

Why handle this port differently from other ports that have this problem (where we use "conflicts_build ${name}")?



More information about the macports-dev mailing list