This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 42071 - autoscan produces bad AC_INIT call
autoscan produces bad AC_INIT call
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: autoconf (Show other bugs)
7.1
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Jens Petersen
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-23 21:26 EDT by Wagner T. Correa
Modified: 2007-04-18 12:33 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-10 07:01:50 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Wagner T. Correa 2001-05-23 21:26:11 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2smp i686)

Description of problem:
autoscan produces a configure.scan with a call to AC_INIT(config.h).   This
is bad, because if you run configure from a build tree that is not the
source tree, config.h will not be found.

How reproducible:
Always

Steps to Reproduce:
1. Run autoscan in some source tree.
2. Copy configure.scan to configure.in.
3. Create configure (run autogen.sh or bootstrap).
4. cd to some directory outside the source tree.
5. Call configure from there.


Actual Results:  configure will fail because it will not find config.h.


Expected Results:  autoscan should have used some other file in the call to
AC_INIT.

Additional info:

rpm -q autoconf
autoconf-2.13-10
Comment 1 Jens Petersen 2001-06-29 04:45:19 EDT
Thank you for the report.

I am sorry but I don't really understand.
Are you claiming that "conf.h" is a bad choice
of file to detect. What would be a better choice?
Why?

I cannot reproduce this:

sh-2.05$ mkdir tmp
sh-2.05$ cd tmp
sh-2.05$ touch conf.h
sh-2.05$ autoscan
sh-2.05$ mv configure.scan configure.in
sh-2.05$ cat configure.in 
dnl Process this file with autoconf to produce a configure script.
AC_INIT(conf.h)

dnl Checks for programs.

dnl Checks for libraries.

dnl Checks for header files.

dnl Checks for typedefs, structures, and compiler characteristics.

dnl Checks for library functions.

AC_OUTPUT()
sh-2.05$ autoconf
sh-2.05$ ls
conf.h
configure  configure.in
sh-2.05$ mkdir build
sh-2.05$ cd build/
sh-2.05$ ../configure
creating cache ./config.cache
updating cache ./config.cache
creating ./config.status
sh-2.05$ ls
config.cache  config.log  config.status
Comment 2 Wagner T. Correa 2001-06-29 15:10:07 EDT
Petersen, as far as I understand, the configure script is supposed to
create config.h in the build tree, and a developer should not include
config.h in the distribution.  Therefore, autoscan shouldn't look for
it in the source tree.

It seems to me that this is the whole point of using configure.  The
user of the package would run configure to create a config.h that fits
his environment.  If the developer includes config.h in the
distribution, he is limiting the package to the development
environment.

The following is the smallest example I could come up with of how to
reproduce the bug.  It ended up being not that small...

% mkdir hello
% cd hello
% mkdir src
% cd src
% vi hello.c
% cat hello.c

#include <stdio.h>
int main(void)
{
	printf("Hello, world!\n");
	return 0;
}

% vi Makefile.am
% cat Makefile.am

bin_PROGRAMS = hello
hello_SOURCES = hello.c

% cd ..
% vi Makefile.am
% cat Makefile.am

SUBDIRS = src

% vi configure.in
% cat configure.in

AC_INIT(src/hello.c)
AM_CONFIG_HEADER(config.h)
AM_INIT_AUTOMAKE(hello, 0.0.1)
AC_PROG_CC
AC_OUTPUT(Makefile src/Makefile)

% touch NEWS README AUTHORS ChangeLog
% aclocal ; autoheader ; automake --add-missing ; autoconf

automake: configure.in: installing `./install-sh'
automake: configure.in: installing `./mkinstalldirs'
automake: configure.in: installing `./missing'
automake: Makefile.am: installing `./INSTALL'
automake: Makefile.am: installing `./COPYING'

% ./configure

creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating src/Makefile
creating config.h

% make

make  all-recursive
make[1]: Entering directory `/home/wtcorrea/hello'
Making all in src
make[2]: Entering directory `/home/wtcorrea/hello/src'
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c hello.c
gcc  -g -O2  -o hello  hello.o  
make[2]: Leaving directory `/home/wtcorrea/hello/src'
make[2]: Entering directory `/home/wtcorrea/hello'
make[2]: Leaving directory `/home/wtcorrea/hello'
make[1]: Leaving directory `/home/wtcorrea/hello'

% src/hello

Hello, world!

% make dist
% cp hello-0.0.1.tar.gz /tmp
% cd /tmp
% tar xvfz hello-0.0.1.tar.gz
% cd hello-0.0.1
% ./configure 

creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... yes
checking whether the C compiler (gcc  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating src/Makefile
creating config.h

% make
make  all-recursive
make[1]: Entering directory `/tmp/hello-0.0.1'
Making all in src
make[2]: Entering directory `/tmp/hello-0.0.1/src'
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c hello.c
gcc  -g -O2  -o hello  hello.o  
make[2]: Leaving directory `/tmp/hello-0.0.1/src'
make[2]: Entering directory `/tmp/hello-0.0.1'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/tmp/hello-0.0.1'
make[1]: Leaving directory `/tmp/hello-0.0.1'

So, everything works so far.  Now, let's say I decide to run autoscan
in my source tree to check if my configure.in is missing something.

% cd ~/hello
% autoscan
% cat configure.scan

dnl Process this file with autoconf to produce a configure script.
AC_INIT(config.h)

dnl Checks for programs.
AC_PROG_AWK
AC_PROG_CC
AC_PROG_INSTALL
AC_PROG_LN_S

dnl Checks for libraries.

dnl Checks for header files.

dnl Checks for typedefs, structures, and compiler characteristics.

dnl Checks for library functions.

AC_OUTPUT(Makefile src/Makefile)

autoscan calls a few other AC_PROG macros that I should add to my
configre.in, which is fine.  The problem is the call to AC_INIT, which
uses config.h.  Let's say I change that call in my configure.in.

% vi configure.in
% cat configure.in

AC_INIT(config.h)
AM_CONFIG_HEADER(config.h)
AM_INIT_AUTOMAKE(hello, 0.0.1)
AC_PROG_CC
AC_OUTPUT(Makefile src/Makefile)

% aclocal ; autoheader ; automake --add-missing ; autoconf
% ./configure

It works fine here in the developer's source tree.  But...

% make dist
% rm -rf /tmp/hello-0.0.1 /tmp/hello-0.0.1.tar.gz
% cp hello-0.0.1.tar.gz /tmp
% tar xvfz hello-0.0.1.tar.gz
% cd hello-0.0.1
% ./configure 

configure: error: can not find sources in . or ..

That's the problem.  The user can't configure the package because
config.h is not part of the distribution, as it shouldn't be.  Thus,
AC_INIT shouldn't be called with config.h.

Phew...
Comment 3 Jens Petersen 2001-07-02 05:04:12 EDT
Thanks for the detailed example.

The patch below should fix the problem.  It makes autoscan
use <filename>.in instead of <filename> when the former
exists.  It is based on a patched version of sub wanted in
2.50.  A patch has been sent to autoconf-patches also to
reflect this.

--- autoconf-2.13/autoscan.pl~	Mon Jul  2 17:58:04 2001
+++ autoconf-2.13/autoscan.pl	Mon Jul  2 17:58:04 2001
@@ -121,16 +121,28 @@
 
 # Collect names of various kinds of files in the package.
 # Called by &find on each file.
-sub wanted
+sub wanted ()
 {
-    if (/^.*\.[chlymC]$/ || /^.*\.cc$/) {
-
$name =~ s?^\./??; push(@cfiles, $name);
-    }
-    elsif (/^[Mm]akefile$/ || /^[Mm]akefile\.in$/ || /^GNUmakefile$/) {
-
$name =~ s?^\./??; push(@makefiles, $name);
-    }
-    elsif (/^.*\.sh$/) {
-
$name =~ s?^\./??; push(@shfiles, $name);
+  # Strip a useless leading `./'.
+  $name =~ s,^\./,,;
+
+  if (! -f "$_.in")
+    {
+     if (/^.*\.[chlymC](\.in)?$/ || /^.*\.cc$/)
+     {
+       push (@cfiles, $name);
+     }
+     elsif (/^[Mm]akefile(\.in)?$/ || /^GNUmakefile$/)
+     {
+       # Wanted only if there is no corresponding Makefile.in.
+       # Using Find, $_ contains the current filename with the current
+       # directory of the walk through.
+       push (@makefiles, $name);
+     }
+     elsif (/^.*\.sh(\.in)?$/)
+     {
+       push (@shfiles, $name);
+     }
     }
 }
 

Note You need to log in before you can comment on or make changes to this bug.