[sr #107986] autoconf should reject or specifically warn about obviously wrong configure.ac files

2020-08-18 Thread Zack Weinberg
Update of sr #107986 (project autoconf):

  Status: Need Copyright Assignment => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #7:

I wound up re-doing the code changes from scratch, but this has now been
addressed in aba75f6d4a9c875a9d5d90a07c6b3678db66a4bf and
6a0c0239449a98181c5dd7e505cddbc0840471a4.

Further improvements to autoconf's ability to detect erroneous configure
scripts would be welcome.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #107986] autoconf should reject or specifically warn about obviously wrong configure.ac files

2020-07-16 Thread David A. Wheeler
Follow-up Comment #6, sr #107986 (project autoconf):

[comment #5 comment #5:]
> Hm, I think this is still a desirable change and could be merged for 2.70. 
David Wheeler, if you're still reading this, do you have a copyright
assignment on file with the FSF for changes to autoconf?  I don't see your
name in the git log or any of the old changelogs.

Thanks so much for the vote of confidence! I'm working right now on the
copyright assignment with my former employer (I just got the revised FSF
paperwork today). My former employer has done this before, so I think this
will be resolved soon. I'm hoping this improvement can be merged into autoconf
2.70.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #107986] autoconf should reject or specifically warn about obviously wrong configure.ac files

2020-07-16 Thread Zack Weinberg
Update of sr #107986 (project autoconf):

  Status:   Need Info => Need Copyright Assignment


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #107986] autoconf should reject or specifically warn about obviously wrong configure.ac files

2020-07-10 Thread Zack Weinberg
Update of sr #107986 (project autoconf):

  Status:None => Need Info  

___

Follow-up Comment #5:

Hm, I think this is still a desirable change and could be merged for 2.70. 
David Wheeler, if you're still reading this, do you have a copyright
assignment on file with the FSF for changes to autoconf?  I don't see your
name in the git log or any of the old changelogs.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/




[sr #107986] autoconf should reject or specifically warn about obviously wrong configure.ac files

2012-04-07 Thread David A. Wheeler
Follow-up Comment #4, sr #107986 (project autoconf):

Okay, here's a better patch.  This one will warn if someone fails to use
AC_INIT in configure.ac, when you use either autoconf or autoreconf.  It adds
an option flag, in case you want to skip the check.  It also checks the
AC_INIT parameters and warns if they are not normalized.  Finally, some
changes to the test suite to add tests and make them pass.

(file #25606)
___

Additional Item Attachment:

File name: autoconf-ac-init.patch Size:5 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/




Re: [sr #107986] autoconf should reject or specifically warn about obviously wrong configure.ac files

2012-03-18 Thread David A. Wheeler
Eric Blake said:
> Follow-up Comment #1, sr #107986 (project autoconf):
> 1. AC_INIT is essential, AC_OUTPUT is optional but useful; and makes the most
> sense if any AC_CONFIG_ were used.  It's probably possible to wire up
> something along those lines (for AC_INIT: have the autoconf driver trace
> AC_INIT, and error out if the trace was not present; ... Patches welcome.

Okay, below is a git format-patch for AC_INIT as described above.  With this 
patch, if "autoconf" is invoked using an empty "configure.ac" (for example), it 
correctly fails and reports:
  autoconf: error: Failed to use AC_INIT in the input file configure.ac.

HOWEVER, autoreconf seems to ignore and hide ALL errors returned by autoconf, 
including this one, so "autoreconf -i" doesn't error out as I expected.  That 
behavior seems fundamentally wrong.  Is that the *expected* behavior?  Or am I 
missing something obvious?

--- David A. Wheeler

=

From fa2c21b986684fb4620b38d744487610849612af Mon Sep 17 00:00:00 2001
From: "David A. Wheeler" 
Date: Sun, 18 Mar 2012 14:02:29 -0400
Subject: [PATCH] autoconf: Fail if AC_INIT not used

---
 bin/autoconf.as |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/bin/autoconf.as b/bin/autoconf.as
index aa85394..48dc105 100644
--- a/bin/autoconf.as
+++ b/bin/autoconf.as
@@ -183,6 +183,14 @@ esac
 # Unless specified, the output is stdout.
 test -z "$outfile" && outfile=-

+# Check to ensure there is an AC_INIT, via autom4te's tracing capabilities.
+eval set x "$autom4te_options" \
+  --language=autoconf --output=\"-\" "--trace=AC_INIT" \"\$infile\"
+shift
+if test -z "$traces"  && test -z "`"$AUTOM4TE" "$@"`" ; then
+  AS_ERROR([Failed to use [AC_INIT] in the input file $[]infile.])
+fi
+
 # Run autom4te with expansion.
 eval set x "$autom4te_options" \
   --language=autoconf --output=\"\$outfile\" "$traces" \"\$infile\"
--
1.7.7.6




[sr #107986] autoconf should reject or specifically warn about obviously wrong configure.ac files

2012-03-18 Thread David A. Wheeler
Follow-up Comment #3, sr #107986 (project autoconf):

Oh, a quick note about the attached patch to require AC_INIT - this patch will
currently cause "make check" in autoconf to fail, because some of the autoconf
test cases don't call AC_INIT either :-(.

Possible solutions include:
1. Fix all the tests so that they use AC_INIT
2. Create an option flag meaning "do not require AC_INIT", and change those
tests to use it
3. Make omitting AC_INIT a warning, not an error.

All the above would *work*.  Turning the omission of AC_INIT into a warning
might be the easiest upward-compatible approach.  However, which one is most
acceptable to the autoconf developers?


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/




[sr #107986] autoconf should reject or specifically warn about obviously wrong configure.ac files

2012-03-18 Thread David A. Wheeler
Follow-up Comment #2, sr #107986 (project autoconf):

Okay, I have developed a git format-patch (attached) to detect a failure to
use AC_INIT. With this patch, if "autoconf" is invoked using an empty
"configure.ac" (for example), it correctly fails and reports:
autoconf: error: Failed to use AC_INIT in the input file configure.ac.

HOWEVER, autoreconf seems to ignore and hide ALL errors returned by autoconf,
including this one, so "autoreconf -i" doesn't error out as I expected. That
behavior seems fundamentally wrong. Is that the *expected* behavior? Or am I
missing something obvious?

This doesn't do everything I suggested, but it's a first step and useful.  I
think it's better to do this sort of thing incrementally, so here is an
increment.


(file #25396)
___

Additional Item Attachment:

File name: 0001-autoconf-Fail-if-AC_INIT-not-used.patch Size:0 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/




[sr #107986] autoconf should reject or specifically warn about obviously wrong configure.ac files

2012-03-16 Thread Eric Blake
Follow-up Comment #1, sr #107986 (project autoconf):

1. AC_INIT is essential, AC_OUTPUT is optional but useful; and makes the most
sense if any AC_CONFIG_ were used.  It's probably possible to wire up
something along those lines (for AC_INIT: have the autoconf driver trace
AC_INIT, and error out if the trace was not present; for AC_OUTPUT: have
AC_INIT install an m4_wrap that warns if AC_OUTPUT has not been expanded). 
Patches welcome.

Yes, a warning for a trailing space in a package version name or number might
make sense; we can't warn everywhere, and it should not be outright forbidden,
but hopefully the warning will help.  Patches welcome.

3. It's hard to pro-actively fix everything, without knowing what sort of
mistakes are being commonly made, and without bloating the tool or slowing it
down for the common and correct use cases.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/




[sr #107986] autoconf should reject or specifically warn about obviously wrong configure.ac files

2012-03-15 Thread anonymous
URL:
  

 Summary: autoconf should reject or specifically warn about
obviously wrong configure.ac files
 Project: Autoconf
Submitted by: None
Submitted on: Fri 16 Mar 2012 05:23:10 AM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: dwhee...@dwheeler.com
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

The key input to autoconf is "configure.ac", but "obviously wrong"
configure.ac files just sail through.  This is bad, especially for people just
starting to learn autoconf, because a simple typo can produce
mysterious-to-them results.  Autoconf should detect at least some "obviously
wrong" situations, like any other compiler, and complain specifically about
problems so they can be fixed quickly instead of debugged.

1. autoconf should fail loudly if either AC_INIT or AC_OUTPUT are missing, and
specifically say "AC_INIT missing" and/or "AC_OUTPUT missing".

2. If AC_INIT's first parameter contains any whitespace, it should at least
warn.  A common beginner mistake is to think that whitespace is irrelevant in
m4, e.g.:
  AC_INIT( hello , 0.01 )
but the trailing whitespace is actually part of the parameter.  If there *is*
no first parameter (or it's empty), that should probably emit a warning.

3. If there are some other places where beginners are likely to make a mistake
(e.g., whitespace at the end that would probably cause a problem), autoconf
should detect it and either warn or error out.

This would make autoconf easier to work with, since problems would be
immediately and specifically identified, instead of having to debug them.

Thank you!





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/