Is there a way to insert a short pause?

[Dr. David Kirkby]

If one runs a configure script, and it needs to show a warning for some
reason, that could be missed by someone quite easily. Is there a way I
could insert a 10s or so pause, so it becomes more obvious, and they
hopefully take time to read the warning?


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Mike Frysinger]

On Thursday 15 October 2009 04:35:22 Dr. David Kirkby wrote:
> If one runs a configure script, and it needs to show a warning for some
> reason, that could be missed by someone quite easily. Is there a way I
> could insert a 10s or so pause, so it becomes more obvious, and they
> hopefully take time to read the warning?

ive found that AC_MSG_WARN is pretty good at catching the eye.  i abuse
whitespace too though:
AC_MSG_WARN([

read this
])
-mike


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ben Pfaff]

"Dr. David Kirkby" <david.kirkby@...> writes:

> If one runs a configure script, and it needs to show a warning for
> some reason, that could be missed by someone quite easily. Is there a
> way I could insert a 10s or so pause, so it becomes more obvious, and
> they hopefully take time to read the warning?

One way to make it more likely that a user will see your warning
is to output it at the end of the configure script, after all of
the tests have completed.
--
"MONO - Monochrome Emulation
 This field is used to store your favorite bit."
--FreeVGA Attribute Controller Reference



_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Bob Friesenhahn]

On Thu, 15 Oct 2009, Ben Pfaff wrote:
>
> One way to make it more likely that a user will see your warning
> is to output it at the end of the configure script, after all of
> the tests have completed.

Yes, this is usually the only bit of configure output that users will
ever look at, and just because it is still on their screen when they
return from the coffee machine.

It would be good if autoconf provided an official way to produce
deferred accumulated warning text displayed the end of the configure
run.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

* Bob Friesenhahn wrote on Thu, Oct 15, 2009 at 07:59:18PM CEST:
>
> It would be good if autoconf provided an official way to produce
> deferred accumulated warning text displayed the end of the configure
> run.

What measure would you suggest for the case where more than a screenful
of deferred messages are displayed?

I don't like things to go yet another step up the importance race.
You can currently just print things after AC_OUTPUT.  I consider it
a feature that only the configure.ac author, as opposed to any macro
author, to be able to write there: it prevents a race on this front.

People have complained about configure being too verbose before, and
about config.log being too long or not easy enough to analyze.  The
solution to this, IMVHO, is not to make it shorter or longer or allow
for even more prominent message, but to try to be smarter in what we
produce.  This can be very difficult to achieve without sacrificing
portability (in the sense that we still give enough clues for even
remote kinds of errors).

For those who want silence except for warnings, they can use -q.

Cheers,
Ralf


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Bob Friesenhahn]

On Thu, 15 Oct 2009, Ralf Wildenhues wrote:

> * Bob Friesenhahn wrote on Thu, Oct 15, 2009 at 07:59:18PM CEST:
>>
>> It would be good if autoconf provided an official way to produce
>> deferred accumulated warning text displayed the end of the configure
>> run.
>
> What measure would you suggest for the case where more than a screenful
> of deferred messages are displayed?

Scrolling. :-)

If even one warning message is evident at the end of the configure
run, it seems likely that the user will know to scroll back to see the
rest. Even a final single message which says "There were warnings
issued, please inspect the configure output or config.log for details"
would be useful.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

* Bob Friesenhahn wrote on Thu, Oct 15, 2009 at 08:18:58PM CEST:
> If even one warning message is evident at the end of the configure
> run, it seems likely that the user will know to scroll back to see
> the rest.

Unless, of course, that rest is so long that the user won't read it all.
There are so many bug reports where users already fail to read past a
  make: *** [foo] Error 1

to paste the full compiler error and its command.

> Even a final single message which says "There were
> warnings issued, please inspect the configure output or config.log
> for details" would be useful.

That, on the other hand, sounds like an interesting idea.  We could
easily let configure print something like
  configure: WARNING: There have been warnings during this configure run.

when it has come across a AC_MSG_WARNING.  WDYT?

Thanks,
Ralf


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Paolo Bonzini-2]

On 10/15/2009 08:29 PM, Ralf Wildenhues wrote:
> That, on the other hand, sounds like an interesting idea.  We could
> easily let configure print something like
>    configure: WARNING: There have been warnings during this configure run.
>
> when it has come across a AC_MSG_WARNING.  WDYT?

Interesting indeed.  I see two things making this non-trivial though.

The first is that you want to be friendly to warning inside subshells.
This means you have to grep config.log for warnings and be careful about
false positives (or maybe "grep -F WARNING:" is enough?)

The second is how to handle AC_CONFIG_SUBDIRS.

Paolo


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Richard Ash-6]

On Fri, 2009-10-16 at 09:27 +0200, Paolo Bonzini wrote:
> On 10/15/2009 08:29 PM, Ralf Wildenhues wrote:
> > That, on the other hand, sounds like an interesting idea.  We could
> > easily let configure print something like
> >    configure: WARNING: There have been warnings during this configure run.
> >
> > when it has come across a AC_MSG_WARNING.  WDYT?
Definitely useful. Could it come out along with AC_OUTPUT, so that
existing "last thing configure says" output (which is done as you
describe) doesn't get pushed away by warnings?

> Interesting indeed.  I see two things making this non-trivial though.
>
> The first is that you want to be friendly to warning inside subshells.
> This means you have to grep config.log for warnings and be careful about
> false positives (or maybe "grep -F WARNING:" is enough?)
Can we anchor the pattern to it's place on the line, so if the
configure.ac writer puts WARNING somewhere in an info message it doesn't
cause a false positive. I was thinking of ^WARNING except the lines
start with file name and line number, something like

^configure: [0-9].: WARNING:

might do it (until we find what grep is and isn't capable of on
different platforms).

> The second is how to handle AC_CONFIG_SUBDIRS.

I could live with "don't" or requiring configure.ac-writer intervention,
because this tends to cause spurious warnings if the sub-configure has
fewer options than top level (e.g. configure: WARNING: unrecognized
options: --with-wx-config, because I'm building 3rd-party sub-libraries
that don't need wxWidgets, but top level does, and needs the option to
find it's libraries).

In other words, I can think of significant other things to change round
AC_CONFIG_SUBDIRS, which might make it easier or harder to implement.

Richard



_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Paolo Bonzini-2]

On 10/16/2009 11:38 PM, Richard Ash wrote:
> ^configure: [0-9].: WARNING:
>
> might do it (until we find what grep is and isn't capable of on
> different platforms).

No, until someone renames configure. :-)

Paolo


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Steffen Dettmer-2]

On Thu, Oct 15, 2009 at 10:35 AM, <david.kirkby@...> wrote:
> If one runs a configure script, and it needs to show a warning
> for some reason, that could be missed by someone quite easily.
> Is there a way I could
> insert a 10s or so pause, so it becomes more obvious, and they hopefully
> take time to read the warning?

Isn't "sleep 10" portable?
Maybe better use AC_MSG_ERROR unless some --disable-error-xyz is given?

I'm afraid in most cases configure warnings are ignored anyway,
as long as make install works, so I think best to compile-in the
state of all affecting options and show them e.g. in ./myprg --version
and require this as mandatory information in bug reports.

oki,

Steffen


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Steffen Dettmer-2]

On Thu, Oct 15, 2009 at 8:29 PM, Ralf Wildenhues wrote:
>  configure: WARNING: There have been warnings during this configure run.
>
> when it has come across a AC_MSG_WARNING.  WDYT?

(I have difficulties to understand why warnings are needed for
except debug/tracing - for end users, I think, either it worked
or failed)

Beside subshells and SUBDIRS, I think also it should be
considered that configure is called by make when needed (e.g.
working on checked out sandboxes that update) and thus other
developers, who probably are the target audience for the
warnings, still would miss the messages and that (probably) often
configure and/or make are called via scripts, wrappers or some
./configure && make construction, I think.

In my team we once had discussions how to handle automatically
disabled features - as one cause for AC_MSG_WARNING. My impression
was that this was not useful (e.g. you accidently built an RPM
without the most important features) and we changed to use some
AC_MSG_ERROR([....... try --disable-xyz...]). Everything of the
platform that looks strange should not (only) lead to a configure
warning but to a failing unit test if possible. I think for
developers this OK (and people can fix and check unit tests
again, having some safety). End users usually should not install
a package where unit tests fail (e.g. --disable the non-working
features).

BTW, does configure support some option to treat warnings as errors
(like gcc -Werror option)? Would it be useful?

oki,

Steffen


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Steffen Dettmer-2]

On Fri, Oct 16, 2009 at 11:38 PM, <richard@...> wrote:
> ...handle AC_CONFIG_SUBDIRS...
>
> I could live with "don't"

I would dislike that because people could start to rely on such
an information (in a few years when all configure scripts are
updated) and would miss the recursive warnings (where the feature
would be most helpful due to the bigger length of output).

I think it should be reliable or not given at all.

> or requiring configure.ac-writer intervention,
> because this tends to cause spurious warnings if the sub-configure has
> fewer options than top level (e.g. configure: WARNING: unrecognized
> options: --with-wx-config, because I'm building 3rd-party sub-libraries
> that don't need wxWidgets, but top level does, and needs the option to
> find it's libraries).

Does this mean recent autoconf versions generate "unrecognized
options" warnings?
I always thought that autoconf does NOT generate such warnings
exactly because of recursive configures? Was this changed?
(in this case this could make usage of AC_SUBDIRS even more
difficult in practice and disencouradge people to use it - but I
really love this feature; good for orthogonality
[package/subpackage independence]).

oki,

Steffen


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf