Subject: configure running twice

From: Dominik Vogt <[email-masked]>
Date: Tue, 26 Jan 1999 23:09:17 +0100

I noticed this while building the code I checked out on 23-Jan
(from scratch):

 # ./configure

runs as usual

 # make

produces this output:

cd . && aclocal
cd . && automake --gnu Makefile
cd . && autoconf
configure.in:159: warning: AC_TRY_RUN called without default to allow cross compiling
configure.in:213: warning: AC_TRY_RUN called without default to allow cross compiling
/bin/sh ./config.status --recheck
running /bin/sh ./configure  --no-create --no-recursion
loading cache ./config.cache
checking for a BSD compatible install... (cached) /usr/bin/ginstall -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... found
checking for working autoconf... found
...
checking for readline/readline.h... (cached) yes
creating ./config.status

Configuration:

  FVWM Version:             2.1.11

  Build extra modules?      no
  Have ReadLine support?    yes
  Have RPlay support?       yes
  Have XPM support?         yes

cd . \
  && CONFIG_FILES=Makefile CONFIG_HEADERS= /bin/sh ./config.status
creating Makefile
...

Seems like configure is unnecessarily called again from make.
Not very nice and a complete waste of time.

Bye

Dominik

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Chris Rankin <[email-masked]>
Date: Tue, 26 Jan 1999 20:56:37 -0500 (EST)

> loading cache ./config.cache

Yup, I see this too - but it's not quite such a major pain in the butt
now that configure ignores the config.cache file when determining
whether or not to use ncurses. Previously it was creating correct
Makefiles for the first configure and then replacing them with
"termcap" ones: VERY frustrating.

Chris.

---

From: [email-masked] (Paul D. Smith)
Date: 26 Jan 1999 21:33:06 -0500

This only happens if make thinks your setup is out of date for some
reason.  It won't happen again after the first time (unless you changed
configure.in or something).

Once we remove the derived files like configure, etc. from the source
tree this should go away.

This is actually a feature: it's the thing that ensures all the derived
files are properly updated when you change something.  But, if the
timstamps on the derived files are out of whack, then it rebuilds.
Can't have one without the other, ya know! :)

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Steve Robbins <[email-masked]>
Date: Tue, 26 Jan 1999 23:43:07 -0500 (EST)

> configure.in or something).

Furthermore, it only happens with CVS sources.  If you unpack a tarball,
the timestamps are correct.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 27 Jan 1999 18:47:40 +0100

> the timestamps are correct.

But then how should the timestamps look like? And why does
this happen even if you run configure immediately before the
make?

Bye

Dominik

---

From: [email-masked] (Paul D. Smith)
Date: 27 Jan 1999 13:31:50 -0500

%% Dominik Vogt <[email-masked]> writes:

  >> the timestamps are correct.

  dv> But then how should the timestamps look like? And why does
  dv> this happen even if you run configure immediately before the
  dv> make?

Configure only builds config.h from config.h.in and Makefiles from
Makefile.in's.

The remake you're talking about happens because the timestamps for
configure.in, or one of the Makefile.am's, or something is out of date;
thus make decides it needs to rebuild configure itself (which then
re-runs the configure script, too, to be safe), config.h.in, or
Makefile.in.

I'm not sure exactly which one, but configure doesn't build the .in
files so running configure won't effect them.

I don't know offhand all the timestamp rules, but basically configure
must be newer than configure.in and aclocal.m4, which must be newer than
acconfig.h.  There's some dependency on acinclude.m4 and config.h.in in
there, too.

Also, all the Makefile.in files depend on Makefile.am and configure.in,
of course.