On 07/12/2017 08:02 PM, Dan Wilcox wrote:
I'm currently updating the INSTALL.txt instructions and am wondering if we should distribute the Pd sources with the configure script ready to go, like most other OSS packages. This way most users don't need autoconf and don't have to run ./autogen.sh. OTOH that's not really a huge dependency when users are already installing the build chain.
I tend towards shipping a minimal package (without configure, config.guess, config.sub,...), and rely on users having to run ./autogen.sh
my reasons: - these days many packages use `git archive` to create the source tarballs. i guess they mostly do this unconsciously, e.g. by using github's "tag as release" mechanism. but afaics this has mostly superseded more traditional ways of distributing source code. miller has expressed his wish to do something like this as well. and i'm a very strict opponent of including *anything* that is generated automatically from some other source into the git repository. so these days i somewhat doubt the truth of "distribute [...] with the configure script ready to go, like *most* other OSS packages" [emphasis mine]
- the other reason is with my Debian packager hat on: the generated autotools scripts are mostly a nuisance anyhow, as they will only reflect whichever outdated/obsolete autotools version the user who created the source tarball had installed. esp. when it comes to supporting uncommon architectures, it is mostly helpful to use the "most recent" autotools available. as a result, all packages in Debian are urged to remake the autotools artifacts (e.g. running 'autoreconf').
from a more general pov, i agree that compared to having to install all kinds of libraries and whatnot, autoconf/automake is not that huge of an additional burden.
the biggest drawback is of course that traditional wisdom has it, that the autotools artifacts ought to be included.
gmasrd IOhannes