Bug 42073 - autoscan fails to call AC_PROG_CXX
autoscan fails to call AC_PROG_CXX
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:38 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 06:54:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Here is the patch I just posted as a attach, since mozilla seemed to break the one above. (1.36 KB, patch)
2001-07-10 06:54 EDT, Jens Petersen
no flags Details | Diff

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

Description of problem:
autoscan fails to add to configure.scan a call to AC_PROG_CXX when the
source tree has C++ files.

How reproducible:
Always

Steps to Reproduce:
1. Run autoscan on a source tree containing C++ files.


Actual Results:  The generated configure.scan will not have a call to
AC_PROG_CXX.

Expected Results:  autoscan should recognize C++ fiiles and add AC_PROG_CXX
to configure.scan.

Additional info:

rpm -q autoconf
autoconf-2.13-10
Comment 1 Jens Petersen 2001-07-10 06:46:06 EDT
Thanks for the report.

The patch below should fix this.  (A corresponding patch was
contributed to autoconf-cvs.)

--- autoconf-2.13/autoscan.pl~	Tue Jul 10 19:00:10 2001
+++ autoconf-2.13/autoscan.pl	Tue Jul 10 19:00:10 2001
@@ -123,14 +123,33 @@
 # Called by &find on each file.
 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);
+  # Wanted only if there is no corresponding FILE.in.
+  return
+    if -f "$_.in";
+
+  # Strip a useless leading `./'.
+  $name =~ s,^\./,,;
+
+  if (/^.*\.[chlymC](\.in)?$/)
+    {
+      push (@cfiles, $name);
+      $programs{cc}++;
+    }
+  elsif (/^.*\.(cc|cpp|cxx|CC|C|hh|hpp|hxx|HH|H|yy|ypp|ll|lpp)(\.in)?$/)
+    {
+      push (@cfiles, $name);
+      $programs{CC}++;
+    }
+  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);
     }
 }
 
@@ -244,7 +263,7 @@
 	    $libraries{$1}++;
 	}
 	# Tokens in the code.
-
while (s/\W([a-zA-Z_]\w*)\W/ /) {
+
while (s/\W([a-zA-Z_][\w\+\.-]*)\W/ /) {
 	    $programs{$1}++;
 	}
     }
Comment 2 Jens Petersen 2001-07-10 06:54:40 EDT
Created attachment 23167 [details]
Here is the patch I just posted as a attach, since mozilla seemed to break the one above.

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