Bug 42073 - autoscan fails to call AC_PROG_CXX
Summary: autoscan fails to call AC_PROG_CXX
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: autoconf   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-05-24 01:38 UTC by Wagner T. Correa
Modified: 2007-04-18 16:33 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-10 10:54:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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 10:54 UTC, Jens Petersen
no flags Details | Diff

Description Wagner T. Correa 2001-05-24 01:38:11 UTC
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 10:46:06 UTC
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 10:54:40 UTC
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.