Re: cwrappers (Was: shell wrappers: merge -l nameoflib into a single -lnameoflib)

[Jonathan Perkin <jperkin%joyent.com@localhost>]

* On 2016-09-19 at 12:57 BST, Kamil Rytarowski wrote:

> On 19.09.2016 01:30, David Brownlee wrote:
> > On 12 September 2016 at 14:26, Jonathan Perkin <jperkin%joyent.com@localhost> wrote:
> >> * On 2016-09-12 at 14:20 BST, Ryo ONODERA wrote:
> >>
> >>> I am working on pkgsrc/lang/rust on NetBSD and Linux.
> >>> The older shell wrappers cannot handle "-l m" (whitespace between -l
> >>> and library name, m) and I cannot build some libraries in lang/rust.
> >>>
> >>> I suggest the following patch.
> >>> It does not break
> >>>
> >>> BUILDLINK_TRANSFORM=  l:execinfo:execinfo:elf
> >>>
> >>> like BUILDLINK_TRANSFORM.
> >>>
> >>> What should be confirmed to adopt this change?
> >>
> >> Looks fine to me.  For the record cwrappers already handles this
> >> construct, which is why I didn't notice this issue with lang/rust
> >> prior to importing.
> >>
> >> I'd like to get this integrated before 2016Q3, so I will perform a
> >> bulk build just to check that there are no regressions, but I don't
> >> expect any.
> >>
> >> Results should hopefully be available tomorrow, though it's been a
> >> long time since I did a non-cwrappers build!
> > 
> > Does anyone know what was outstanding for cutting across to using
> > cwrappers by default? A lot of people have been using it for quite a
> > while now, and it would be nice to have only one copy of all that
> > infrastructure :)
> > 
> 
> Could we please enable it by default now, and drop old wrappers after
> the freeze? Package lang/rust is worth it.

No, it's way too late now.  Users can (and always have been able to)
easily opt-in to cwrappers, and I'd encourage everyone to do so, but I
don't want to ship a branch which has a risk of breaking something.

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com