Karl O. Pinc wrote on 2010-03-10:
On 03/10/2010 11:41:49 AM, Alon Bar-Lev wrote:
On Wed, Mar 10, 2010 at 7:39 PM, Karl O. Pinc <k...@meme.com> wrote:
> 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.
You do not understand the tools. Nor the common use of them.
You *MUST* run ./configure when compiling from sources.
You are right, on all of the above. I don't use them every
day.
But, you _don't_ have to run ./configure every time. You
You do. Either explicitly, or after updating the source ("git pull")
because the Makefiles figure that you need to and run config.status twice
(once with options to re-trigger configure, then to regenerate its
AC_OUTPUT files).
yourself wrote that you do the ./configure on the _new_
machine, and then move the tarball to the old machine
and recompile. This is often the situation, or at least
I found so, when making rpm spec files.
You need to run ./configure on the _new_ (distributor's) machine so that
there is a "Makefile" that you can run "make dist" (to generate a tarball)
or "make distdir" (to rsync the dist' directory), and for no other
purpose. None of the outputs so generated make it to the tarball. If they
did, that would be a bug in Makefile.am or in automake (the latter I've
never seen, or at least I don't recall having seen those).
You are quite correct in pointing out that ./configure
should be able to be run on the old machine, which
means that it can be executed within the build portion
of the spec file.
It's a requisite, but run in the RPM's "prep" section rather than "build".
Most distros today would have %configure macros to feed their distribution
default options in (directory layout, CFLAGS for hardening, and
thereabouts).
HTH
--
Matthias Andree
