From: Omar Polo Subject: Re: got-archive(1) To: Benjamin Stürz Cc: gameoftrees@openbsd.org Date: Fri, 29 Dec 2023 19:47:29 +0100 On 2023/12/28 12:51:51 +0100, Benjamin Stürz wrote: > On 12/28/23 10:44, Stefan Sperling wrote> Your tool takes a simple > > [...] > > Tools like autoconf produce unversioned files to be included in the > > tarball and require a more complicated approach than your script > > provides. > [...] > > Managing a list of files to package becomes unavoidable if > > such projects would want to make use of this feature. One such project > > is got-portable. > > > When I used autoconf for my project (https://github.com/riscygeek/bcc), > I'd just run ./autogen.sh and check everything in, before releasing > a new version. After which I ran make full-clean, > a custom rule that removes everything configure-related. > After that I'd create a release on GitHub and use their tarballs. > In retrospect, I should have created a new branch for every release, > and nowadays I'd use my own infrastructure, > but the same principle would still apply, > if I used autoconf (which I thankfully don't). > I don't know if this is the right way to do so, but it worked for me. Just a parethesis: among the various bad things that can be said about autoconf, when they got something right I feel it's deserved to be advertised. In a autoconf-based project, you get for free the `make dist' target which produces a distribution tarball named project-version.tar.gz ready for distribution. With `make distcheck' it will also run your regress suite and some internal checks (like being able to build from a read-only source tree) before producing said distribution tarball. With this distribution tarball, you're not forcing the dependencies on autoconf, automake, libtool, yacc etc on the users. They only need sh, make and cc available (usually.)