Re: [dev] Is there a text editor following the UNIX philosophy?

From: Ismael Luceno <ismael.luceno_AT_gmail.com>
Date: Tue, 15 Feb 2022 21:39:04 +0100

El mar, 15 feb 2022 a la(s) 20:16, Greg Minshall (minshall_AT_umich.edu) escribió:
>
> Ismael,
>
> > These errors mean the named auxiliary build scripts (needed for
> > portability) are not present and must be provided...
>
> thank you for your explanation. i have wondered.
>
> > Technically, it's wrong to ask users to run autoreconf, projects must
> > provide release tarballs with the pregenerated build system at
> > releases, this is not just a convenience, first because that step is
> > not repeatable and there's no way to fix it except by using the exact
> > same autoconf environment, and because other actions might be part of
> > the release process which make a snapshot different from a release
> > tarball (e.g. bundling submodules, automated editing of some files to
> > match the release, etc.).
>
> but, when "users" (such as many of us, but now a growing number of
> others) pick up a "release" via git, my sense is that the authors of the
> package have no (convenient?) way of providing the auxiliary scripts.

Because that's not a proper release from the point of view of autotools.

> so, the "user" must run autoreconf. is that still true? or, is there a
> (convenient) way package authors can allow a simple "./configure && make
> && make install" to work?

The files aren't meant to be part of the development history, but that
doesn't mean they shouldn't be tracked.

A simple way to deal with the problem is to make an extra commit
(outside the main branch) per release to hold these files and tag it
as the release, that makes it trivial for websites like github to make
proper release tarballs.
Received on Tue Feb 15 2022 - 21:39:04 CET