Bodo Moeller <[EMAIL PROTECTED]> wrote:
> An issue that still is open as of yet is what to do with the exported
> header files. Currently, /usr/local/ssl/include/foo.h will
> #include "bar.h"
> which it should't --
> #include <bar.h>
> is better because it cannot conflict with application files.
> However, I'd prefer moving everything to <openssl/bar.h>
> so that it cannot conflict even with other libraries.
> To compile applications that don't know about the new names,
> one would have to add -I/usr/local/ssl/include/openssl to
> their CFLAGS; new applications could use only -I/usr/local/ssl/include,
> and the header files could alternatively be installed in (or linked
> to) /usr/local/include/openssl.
Switching to <> is okay.
Moving everything to /usr/local/ssl/include/openssl doesn't make much sense
though.
- That will leave /usr/local/ssl/include empty except for the subdir.
- Hypothetical conflicts with other libraries are already taken care of by
having the openssl includes in a separate place and using
-I/usr/local/ssl/include.
- It'll require source code changes in all existing applications (makefiles).
To me, moving the includes only makes sense if we're going to get rid of
/usr/local/ssl entirely and instead put things in /usr/local/bin,
/usr/local/lib, and /usr/local/include/openssl (what should happen to certs
and private?).
This raises the question of associating the openssl version with a particular
API, so that developers can assume that an app written for 0.9.X will still
build and work with 0.9.X+1 (or 0.9 vs. 1.0, or 0.9.Xa vs. 0.9.Xb, or ...).
When does a change in the API trigger a version change, and which digit
changes?
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
