[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