[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] issue warnings for more missing optional libraries
From: |
Bruno Haible |
Subject: |
Re: [PATCH] issue warnings for more missing optional libraries |
Date: |
Mon, 19 Oct 2009 22:49:29 +0200 |
User-agent: |
KMail/1.9.9 |
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