Re: git: ddd386c470a1 - main - textproc/krep: [NEW PORT] High-performance string search utility

From: Daniel Engberg <diizzy_at_FreeBSD.org>
Date: Sat, 21 Feb 2026 01:49:32 UTC
On 2026-02-18 21:00, Älven wrote:
> The branch main has been updated by alven:
>
> URL: https://cgit.FreeBSD.org/ports/commit/?id=ddd386c470a1018eb1c0ff0c624eb1b571c9a3be
>
> commit ddd386c470a1018eb1c0ff0c624eb1b571c9a3be
> Author:     Älven <alven@FreeBSD.org>
> AuthorDate: 2026-02-18 16:48:00 +0000
> Commit:     Älven <alven@FreeBSD.org>
> CommitDate: 2026-02-18 19:57:50 +0000
>
>      textproc/krep: [NEW PORT] High-performance string search utility
>      
>      krep is an optimized string search utility designed for maximum throughput and
>      efficiency when processing large files and directories. It is built with
>      performance in mind, offering multiple search algorithms and SIMD acceleration
>      when available.
>      
>      Note: Krep is not intended to be a full replacement or direct competitor to
>      feature-rich tools like grep or ripgrep. Instead, it aims to be a minimal,
>      efficient, and pragmatic tool focused on speed and simplicity.
>      
>      Krep provides the essential features needed for fast searching, without the
>      extensive options and complexity of more comprehensive search utilities. Its
>      design philosophy is to deliver the fastest possible search for the most common
>      use cases, with a clean and minimal interface.
>      
>      WWW: https://github.com/davidesantangelo/krep/
>      
>      Approved by:            db@, yuri@ (Mentors, implicit)
>      Differential Revision:  https://reviews.freebsd.org/D55357
> ---
>   textproc/Makefile                  |  1 +
>   textproc/krep/Makefile             | 26 ++++++++++++++++++++++++++
>   textproc/krep/distinfo             |  3 +++
>   textproc/krep/files/patch-Makefile | 34 ++++++++++++++++++++++++++++++++++
>   textproc/krep/pkg-descr            | 13 +++++++++++++
>   5 files changed, 77 insertions(+)
Hi,

All SIMD "hacks/detection" should be disabled as we have CPUTYPE and the 
current approach is also broken as host might not share the same CPU 
features as target.

Best regard,
Daniel