Re: pkgsrc mktool utility

[Jonathan Perkin <jperkin%mnx.io@localhost>]

* On 2024-08-05 at 21:49 BST, Tobias Nygren wrote:

> On Mon, 5 Aug 2024 15:08:07 +0100
> Jonathan Perkin <jperkin%mnx.io@localhost> wrote:
>
> > If you want to try it out, "cargo install mktool", set
> > TOOLS_PLATFORM.mktool, and apply the following trivial patch:
> >
> >    https://github.com/TritonDataCenter/pkgsrc/commit/18c7342525f6a6ab23531ec48be98936984d312b
> >
> > My general query is how upset would people be if I committed this patch,
> > and others like it in the future?  I wouldn't ever make use of it
> > mandatory, but I would like it to be an easy optional drop-in
> > replacement for any part of the infrastructure where a dedicated tool
> > will far outperform any shell/awk implementation.
>
> There is some prior art with pkgtools/check-portability which
> is a golang program that optionally hooks in when it is installed.
> So in principle it should be fine, but:
>
> My only objection to the patch posted is that you'll need to have a
> version detection strategy from day one if you intend to implement
> multiple functions in this binary over time.

Not necessarily.  I'm happy to own any divergence of future pkgsrc 
changes.  The in-tree implementation should be defined as the one true 
behaviour, and any external implementation must either follow it 100% or 
be defined as broken.

While there are definitely some mk targets I am looking to add 
replacements for (I added initial support for "checksum" this evening), 
I don't think there will be a huge amount, and you only need to run
"cargo install mktool" to get the latest version once support is added.

> I will object to any expensive forking checks in mk/ after how 
> horrendously slow things became on macOS after mk/compiler/clang.mk
> 1.43. It really needs to be reverted and handled via something static
> in mk.conf, set by the bootstrap.

Yeh there are a lot of things that are incredibly slow right now.  You 
may be interested in my performance branch that fixes some of these, at 
the expense of hardcoding some results, e.g.:

  https://github.com/TritonDataCenter/pkgsrc/commits/feature/performance/trunk
  https://github.com/TritonDataCenter/pkgsrc/commit/9627780298caa3af8ccb30138a910bad3e987f4d
  https://github.com/TritonDataCenter/pkgsrc/commit/c4d82bb4f05cc0b7a2981e06ad1c5dc7c7ef3040

Note that mk.conf is too late for a lot of things, which is why I added 
the vars.OPSYS.mk hook directly into bsd.prefs.mk.  This makes a huge 
difference, especially for things like pbulk scans, but unfortunately 
isn't something we can easily implement in a general way.

Cheers,

--
Jonathan Perkin   -   mnx.io   -   pkgsrc.smartos.org
Open Source Complete Cloud   www.tritondatacenter.com