On 03/10/2010 11:19:13 AM, Alon Bar-Lev wrote: > I will try to explain again. > > You have two roles of environments: > > 1. Developer/packager workstation. > > 2. Target environment. > > For example, 1 would be my computer, and 2 would be the old redhat > computer. > > You go to (1) and do: > $ autoreconf -ivf > $ ./configure && make dist > > Now, you transfer the tarball to users, the old redhat computer is > one > of them. The tarball will work WITHOUT ANY AUTOCONF/AUTOMAKE/LIBTOOL > installed. > > I use older environments as (2) such as solaris-8.
And you don't generally want to be running ./configure from within a rpm specfile, so the same is true of using the rpm tools: On machine 2 you download the tarball, the specfile, (and any patches the rpm maintainer wants to include in the packaged version) and run the rpm build tools on the spec file to build a binary rpm. Note that http://www.rpm.org/max-rpm/s1-rpm-inside-scripts.html says: "Once the %prep script has gotten everything ready for the build, the % build script is usually somewhat anti-climactic — normally invoking make, maybe a configuration script, and little else. ... Either the commands required to build the software are simple (such as a single make command), or they are so unique that a macro wouldn't make it easier to write the script. " In other words ./configure is not expected to be run under normal circumstances. The whole point of autoconf is to produce something that can be made into a tarball that only requires "make; make install" to compile and install. Karl <k...@meme.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
