From owner-freebsd-ports@FreeBSD.ORG Sun Dec 31 20:22:50 2006 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3B05E16A40F; Sun, 31 Dec 2006 20:22:50 +0000 (UTC) (envelope-from durian@shadetreesoftware.com) Received: from mailhost.boogie.com (mailhost.boogie.com [70.91.170.29]) by mx1.freebsd.org (Postfix) with ESMTP id 068AF13C428; Sun, 31 Dec 2006 20:22:49 +0000 (UTC) (envelope-from durian@shadetreesoftware.com) Received: from man.boogie.com (man.boogie.com [192.168.1.3]) by mailhost.boogie.com (8.13.8/8.13.8) with ESMTP id kBVKMlAN070089; Sun, 31 Dec 2006 13:22:48 -0700 (MST) (envelope-from durian@shadetreesoftware.com) From: Mike Durian Organization: Shade Tree Software, LLC To: freebsd-ports@freebsd.org Date: Sun, 31 Dec 2006 13:22:44 -0700 User-Agent: KMail/1.9.4 References: <200612291040.29615.durian@shadetreesoftware.com> <45975BFB.2050604@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200612311322.46830.durian@shadetreesoftware.com> X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (mailhost.boogie.com [70.91.170.29]); Sun, 31 Dec 2006 13:22:48 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on fever.boogie.com Cc: Paul Schmehl , Jeremy Chadwick , Doug Barton Subject: Re: www/libwww and SSL X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2006 20:22:50 -0000 On Sunday 31 December 2006 11:18, Paul Schmehl wrote: > --On December 30, 2006 10:43:07 PM -0800 Doug Barton > > wrote: > > Paul Schmehl wrote: > >> What I want isn't really relevant. I'm simply suggesting that updating > >> the port to include an OPTION for with_ssl seems unnecessary *unless* > >> someone is going to port sipX. Have you looked at sipX? Porting it > >> would not be simple, and I wonder how much demand there would be. In > >> any case, *unless* sipX gets ported, it doesn't make sense to me to > >> update www/libwww simply to enable an option no one has asked for until > >> now. > > > > OTOH, what harm does it cause? > > That depends on how the port is patched. If with_ssl is included in every > build, it's hard to say. There may be many unintended consequences. If > with_ssl is included as an OPTION, then when the port is built it will > require someone to be at the console (or an entry in /etc/make.conf.) We've got the source, so we might be able to come up with an answer that is a bit less conjectural. I encourage others to check my analysis. When --with-ssl is defined the configure script expands some variables, WWWSSL, SSLINC, LIBSSL, LWWWSSL, LIBWWWSSL and WWWSSLEX with non-empty values. If --with-ssl is not defined, or set to no, these variables are left empty. These variables are then set in every Makefile in the libwww build. However, the variables are only used in the Makefiles found in the SSL and Examples subdirectory (and children). I think we can ignore the Examples case, unless someone is using one of the examples as more than just an example. The SSL subdirectory is included in every build, even if --with-ssl is not defined. In the case where SSL is not defined, the libwwwssl library does not get built, however the SSL related header files are still installed. When --with-ssl is defined, the libwwwssl library gets built and is installed. As with the non-SSL case, the SSL header libraries are also installed. =46rom this we see that the --with-ssl option only impacts the libwwwssl library itself. It does not impact any of the other libwww libraries (otherwise the SSL variables would have been used in other Makefiles). In particular, --with-ssl only results in libwwwssl libraries getting built and installed. SSL header files are always installed. Defining --with-ssl also impacts the libwww-config script which can be used to generate a list of libraries needed when linking programs that use libwww. In this case, -lwwwssl will be part of the library list and any programs using libwww will also link against -lwwwssl. But, if they aren't calling any functions found in -lwwwssl, it is hard to see how this will make any impact. So, adding --with-ssl will only impact other ports if part of their configuration looks for the libwwwssl library and uses functions in it, if found. That strikes me as a potential benefit to other ports, as it might make possible expanded functionality. We know from PR #99863 that net/xmlrpc-c is one such port. From the PR, we know it will make use of libwwwssl if it is configured using --with-www-ssl, which is not an option in the BSD port Makefile. That's just my $0.02. mike