On 2023/12/28 12:51:51 +0100, Benjamin Stürz <benni+got@stuerz.xyz> 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.)