For the openssl case, all you need to do is look for openssl/ssl.h
in the default include path, and that -lssl -lcrypto can find
SSL_library_init() in the default linker search path. Then I would
change --with-tls to override the base search path for the includes and
libraries. This is how most packages seem to handle it, and it works
fine. Although I would probably rename --with-tls to --with-openssl to
better describe what it does.
Well .... we used to do (something) like that. It turns out that it's
tough to handle that in a portable way. You need to add flags to both
CPPFLAGS and LDFLAGS. CPPFLAGS is generally okay; those flags don't
change much. But a lot of the time you need extra flags to LDFLAGS,
and those aren't always the same across systems. It ends up being a
complicated mess; believe me, I tried hard to make it work. So rather
than specifying a prefix path, it just ends up being easier to require
the user to specify the CPPFLAGS and LDFLAGS arguments directly. If the
packages are in the default search path, everything works fine. If not
... well, it gets hard to get it right automatically. Let packagers
and/or users make the call there.
You can see the discussion back when I made the change to the current
system here:
http://lists.nongnu.org/archive/html/nmh-workers/2010-11/msg00159.html
As an example, on FreeBSD, the above defaults would find the
OpenSSL implementation in the base OS. Configuring with
--with-openssl=/usr/local would find the optional version built from
FreeBSD ports.
I'd rather let the port maintainer for nmh on each platform adjust
that as appropriate.
Given all the fuss over security on the net these days, we really should
be defaulting this stuff to 'ON' whenever possible.
Agreed. That should be relatively straightforward.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers