Are you referring to the configure code? I might be missing something
obvious, but
AC_CHECK_LIB([selinux], [setcon], [SELINUX_LIBS="-lselinux"])
versus
AC_CHECK_HEADER([selinux/selinux.h], [
AC_CHECK_LIB([selinux], [setcon], [SELINUX_LIBS="-lselinux"],
[AC_MSG_RESULT([SELinux library not found.])]
)], [AC_MSG_ERROR([SELinux headers not found.])]
)
doesn't really qualify as "very complex" to me.
Of course it isn't - and it is the better choice - by a mile! The
primary function of configure has always been not only to find out what
the build environment is like, but to also figure out a potential build
problems/missing headers/libraries and _communicate_ those findings, so
that potential errors down the line during the build process are easily
discovered and removed at source.
The last thing I, as a person compiling/building OpenVPN, want is to
debug a config.log and then the configure file itself to find out why a
specific part of OpenVPN build has failed. The former - rather obscure -
statement does not give me that option, while the latter discovers this
and properly communicates it.
2. Detect library only - you assume that if library is present, the
functionality exists, this is what important... no need to check for
header, most probably this exists as well. This makes the code
simpler, in the risk of compile failure if header is missing.
Which is less convenient for the user who expects _configure_ to
figure out those kinds of problems. My expectation would be: If
configure thinks everything is fine, the build should normally compile
without errors unless there's a bug in the lib / the program.
Your two alternatives don't really sound like whether or not we want
auto-detection but more like what kinds of problems to detect at
configure time.
1. detect missing / misplaced libs and missing / misplaced headers
2. detect missing / misplaced libs
Library auto-detection would IMHO be
a) to enable / disable features based on which libraries were found and/or
b) to search additional non-standard paths for the libraries and headers.
Some projects implement b), but I wouldn't recommend it. I tend to
also disagree with a), depending on the dependency. For example, I
could see configure enabling/disabling selinux automatically, unless
explicitly told to use a specific setting.
Exactly - every single word of it!
