Re: git: 132f818ddbf4 - main - contrib/lutok: update from 0.4 to 0.6.2

On Fri, 4 Sep 2026 10:33:30 -0700
"Enji Cooper (yaneurabeya)" <yaneurabeya@gmail.com> wrote:

> > On Sep 4, 2026, at 3:32 AM, Benjamin Jacobs <freebsd@dev.thsi.be> wrote:
> > 
> > Hi,
> > 
> > I was meant to send this to you. I assume that including those
> > build files was unintentional, wasn't it?  
> 
> Hi,
> 	Thank you for following up — I meant to send out a reply to your earlier email.
> 
> 	tl;dr: including these files was actually semi-intentional, but their inclusion is temporary. If you feel like it’s a real problem which deserves fixing, please file an issue with bugs.freebsd.org <http://bugs.freebsd.org/>, or freebsd/atf, freebsd/kyua, and freebsd/lutok (on GitHub).
> 
> 	(If you’re satisfied with the above answer feel free to stop here)
> 
> 	As someone pointed out in https://github.com/freebsd/lutok/issues/37, the release tarballs were incorrectly generated for version 0.6, resulting in broken downstream installs where autotools were not expected to be preinstalled (and weren’t required in past releases). “make dist” doesn’t include the .gitignore files in EXTRA_DIST, so these autotools generated files get checked in to git repos (more easily), for better or worse.
> 	This should be a relatively short-lived change though: the proposed goal originally was to move to cmake with the project, but after doing some research (thanks to prodding by bapt@ and siva@), I think moving to meson is the more sensible route for the projects. I’ll do a bit more research before committing to meson, but it seems like the better of the two popular build system alternatives to autotools (cmake being the other), which doesn’t rely on heavier weight tools like buck or bazel (which rely on Java/Nailgun).
> Thank you,
> -Enji


Hello,

Thanks for answering me in detail.

My understanding is that those release artifacts are useless for
building using FreeBSD's Mk, although necessary from the point of view
of an upstream distribution. I'm also under the impression that it is
customary for other "contrib" software that a bit of post-processing on
the upstream release is done, sometimes from a vendor branch, to remove
extraneous cruft or to merge some local patch before entering the src tree.

And because during the previous import (of version 0.4 thus, whose tarball
on github does contain configure, config.guess, libtool helpers and
whatnot), care was taken to remove them, I thought that this might be
an oversight this time.

It is just a small oddity to see a 11k+ lines diff popping out when
catching up on current... Not enough of a big issue for me, but still
I'm glad to hear that switching from upstream build system will avoid
such noisy change from happening in the future :-)


Best regards,

Benjamin


PS: Maybe the https://github.com/xmake-io/xmake build-system could be
a viable option? It is Lua based, low-dependency (no python, no ninja),
actively developed and it seems to have quite some features and good
c++ (modules) support. I'm just throwing out an idea. TBH, I just found
about it now, looking at http://lua-users.org/wiki/LuaBuildSystems