Re: [PATCH] issue warnings for more missing optional libraries

[Bruno Haible]

Pádraig Brady wrote:
>     configure: WARNING: libacl development library was not found or not 
> usable.
>     configure: WARNING: GNU coreutils will be built without ACL support.
>     configure: WARNING: libselinux was found but selinux/selinux.h is missing.
>     configure: WARNING: GNU coreutils will be compiled without SELinux 
> support.
>     configure: WARNING: libattr development library was not found or not 
> usable.
>     configure: WARNING: GNU coreutils will be built without xattr support.
>     configure: WARNING: libcap development library was not found or not 
> usable.
>     configure: WARNING: GNU coreutils will be built without capability 
> support.
>     configure: WARNING: libgmp development library was not found or not 
> usable.
>     configure: WARNING: GNU coreutils will be built without GMP support

I like it. Even more I like the configure files that print a summary of the
most important decisions or findings at the end of the configuration, thus
giving an opportunity to the user to re-configure with different --with or
--enable options. (Given the size of the configure output, hardly anyone looks
through it in its entirety.)

It looks like this in mono:

  $ ./configure
  ...
  configure: creating ./config.status
  config.status: creating Makefile
  config.status: creating include/Makefile
  config.status: creating include/private/Makefile
  config.status: creating doc/Makefile
  config.status: executing depfiles commands
  config.status: executing default commands

          mcs source:  $(top_srcdir)/mcs
          GC:          included
          TLS:         __thread
          SIGALTSTACK: no
          Engine:      Building and using the JIT
          2.0 Alpha:   yes
          JNI support: IKVM Native
          libgdiplus:  assumed to be installed

Or similarly in GNU clisp:

  $ ./configure
  ...
  Configure findings:
    FFI:        no (user requested: default)
    readline:   yes (user requested: default)
    libsigsegv: no, consider installing GNU libsigsegv

Especially for packages with many dependencies or with many configuration
opportunities it would be useful.

What do you think? Should we pursue this further?

Bruno