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.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
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
I agree with all this reasoning... and moreover, what of .configure files that get out of date and have to be remade anyway? It seems like it's no gift to anyone at all :)
M
On Wed, Jul 12, 2017 at 08:48:37PM +0200, IOhannes m zmölnig wrote:
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
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev