From owner-freebsd-ports@FreeBSD.ORG Mon Feb 21 15:58:10 2005 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A1E716A4CE for ; Mon, 21 Feb 2005 15:58:10 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 1C9C943D1D for ; Mon, 21 Feb 2005 15:58:09 +0000 (GMT) (envelope-from barner@gmx.de) Received: (qmail invoked by alias); 21 Feb 2005 15:58:07 -0000 Received: from unknown (EHLO zi025.glhnet.mhn.de) (129.187.19.157) by mail.gmx.net (mp008) with SMTP; 21 Feb 2005 16:58:07 +0100 X-Authenticated: #147403 Received: by zi025.glhnet.mhn.de (Postfix, from userid 1000) id 7D979C282; Mon, 21 Feb 2005 16:58:32 +0100 (CET) Date: Mon, 21 Feb 2005 16:58:32 +0100 From: Simon Barner To: Kirill Ponomarew Message-ID: <20050221155832.GJ51280@zi025.glhnet.mhn.de> References: <20050221142951.GA48781@pc5-179.lri.fr> <20050221153217.GI51280@zi025.glhnet.mhn.de> <20050221153615.GE9175@voodoo.oberon.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ofZMSlrAVk9bLeVm" Content-Disposition: inline In-Reply-To: <20050221153615.GE9175@voodoo.oberon.net> User-Agent: Mutt/1.5.8i X-Y-GMX-Trusted: 0 cc: ports@freebsd.org cc: Marwan Burelle Subject: Re: devel/pcre and WITH_UTF8 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2005 15:58:10 -0000 --ofZMSlrAVk9bLeVm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kirill Ponomarew wrote: > > A proper solution for this would be a slave port devel/pcre-utf8 that > > enforces the use of the WITH_UTF8 option. (See e.g. devel/boost and > > devel/boost-python for an example). >=20 > OTOH we can't afford to create slave ports for almost every > configure option. Yes, you're right, since there are exponentially many combinations of options, creating slave ports is not the right way. We probably need a mechanism to require compile time options via the dependency mechanism. The following idea just popped into my mind (probably most applicable to OPTIONs): - encode the set of chosen options into the package name - enhance the dependency tracking algorithm to accept the installed version of a port if and only if the set of installed options is a super-set of the set of requested options. Admittedly, this might result in lengthy package names (but that's the same if popular combination of options are encoded as slave ports). Of course, patches are better than RFCs and specifications, so I'll go back to my corner and keep my mouth shut again ;-) Cheers, Simon --ofZMSlrAVk9bLeVm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCGgUoCkn+/eutqCoRArIpAKCXLEVrbVm9POekSEMKZozLsziewQCguSVf VAb5vX4Umef2GmTfJQy7fNs= =1mdh -----END PGP SIGNATURE----- --ofZMSlrAVk9bLeVm--