Niels Poppe <[EMAIL PROTECTED]>:
> In packaging openssl, I change #include "foo.h" to #include <ssl/foo.h>
> and then install all ssl include files into /usr/include/ssl.
> This way nothing changes for openssl internally, but once installed in
> the system location, external programs can include <ssl/foo.h> and be
> sure no local system foo.h will get in the way.
The recursive #include "..."s in OpenSSL's include directory really
all should be #include <...> anyway, which whould avoid any clashes
with application programs. It would not avoid clashes with other
libraries, however, which can be expected to occur quite often.
So I propose introducing <openssl/...> as the official file name
scheme; that is, the files would be installed in /usr/include/openssl/
(or a location with a different prefix in place of /usr/include,
whatever the user chooses). For consistency, the contents of the
include directory in the OpenSSL source code tree (which are just
links to other places) would be moved into a new directory
include/openssl.
If a program assumes that the OpenSSL header files can be reached
as <ssl.h> and the like, it can still simply compiled with
-I/usr/local/include/openssl, so no severe compatibility problem would
be introduced.
Instead of using "openssl" as prefix, just "ssl" is also an
option, but it is not necessarily unique (and it is misleading:
Programs that use the OpenSSL library do not necessarily use SSL, so
it makes more sense to use the product name instead of a protocol
name).
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
