On Sun, Feb 18, 2018 at 10:30:29PM +0100, Klemens Nanni wrote:
> On Sun, Feb 18, 2018 at 07:27:36PM +0100, Sebastien Marie wrote:
> > On Sun, Feb 18, 2018 at 12:21:43PM +0100, Klemens Nanni wrote:
> > >  MODULES =                devel/cargo
> > > +BUILD_DEPENDS =          lang/rust>=1.20 \
> > > +                 textproc/asciidoc
> > 
> > lang/rust isn't necessary as it is automatically added in BUILD_DEPENDS
> > when you have devel/cargo in MODULES.
> I'm aware of that. >=1.20 is important here as it specifies the minimal
> version required to compile ripgrep.

I don't see the need for that.

under -current, lang/rust version is 1.24.
under 6.2, lang/rust version is 1.20.

So such explicit version requirement would be only useful for some
frankenstein port tree, and keep tracking such minimal version could be
a bit resource consuming.

but it isn't wrong per se. I would let more familiar port tree developer to
comment.

> > The following diff takes care of that:
> > - use MODCARGO_RUSTFLAGS as port variable to set RUSTFLAGS in cargo
> >   invocation
> > 
> > - while here, correct (a bit) the license detection (bug reported by
> >   kpcyrd <kpcyrd AT rxv.cc> some time ago).
> > 
> > 
> > With it, adding
> > 
> > MODCARGO_RUSTFLAGS += -C debuginfo=0
> > 
> > to ripgrep's Makefile, makes RUSTFLAGS variable correctly setted and
> > passed to cargo.
> Sounds good to me, thanks for the work.
> 
> > Please note, I am still unsure if strip(1) is need in post-install.
> Stripping results half-sized binaries here.
> 
> As everything except the binary itself gets installed from post-install,
> we can simply turn it into do-install, as this will result in using
> INSTALL_PROGRAM which strips binaries by default.

I agree.

> Updated diffs below for cargo.port.mk and ripgrep in that order. I
> slightly reordered the Makefile according to template.

generally speaking, avoid mixing patches if there are not based on same
directory, as it requires manual processing to get only the right patch.

Thanks.
-- 
Sebastien Marie

Reply via email to