Package locations (Re: commit: ldap configure configure.in)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

>Sometimes ssl.h is ssl/ssl.h.  This is a simple fix so that it is
>detected in those cases,

It's not necessarily that simple.  You could be openning a can
of worms.

What's the source of the odd SSL header location?

OpenSSL and SSLeay, to the best of my knowledge, applications
should use <ssl.h>, not <ssl/ssl.h>.  So should our tests.

There are three main sources of odd installation:
	1) users who select alternative prefixes or directories.
	2) 3rd party repackers who select alternative prefixes,
		directories, and (in some rare cases) alternative
		file names.
	3) operating system vendor repackers who select alternative
		prefixes, directories, and (in some rare cases)
		alternative file names.

It not feasible to resolve all of these problems within configure.
Besides the obvious problem of too many locations to search, there
are ambigitity issues as well as specification of C compiler flag
issues.

The general rule of thumb is for configure to test as a manor
consistent with our use and our use should be consistent with
reference materials for the package (as original distributed).

Users who devivate recommended installation locations (by (1)
or (2)) are basically on their own.  The should choose their
locations (and repackagers) wisely.  Luckily our configure
scripts supports the searching additional include/library
directories through modification of environmental variables.
(Autoconf 1.4 will hopefully support modification of environment
variables via command line flags, ie: --env-VAR=VALUE).

We try to be a bit more flexible in handling operating
system vendor repackaging, especially with any 'required'
or 'recommended' dependent package.  Of course, this can
get real messy (like our pthread detection) and shouldn't
be enterred into lightly.

Anyways, what's the source of the extra 'ssl' subdirectory?
Are the headers within the C translator's default include path?
Are the libraries within the C translator's default library path?

>more work is needed to abstract its location
>so that programs can be compiled without change.

IF we choose to support detection of ssl.h under the ssl
subdirectly, we'd may want to create an <ac/ssl.h> header
to hide the #ifdef hell.

Kurt