man/listinfo/cvs-ports>, List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Dec 2006 19:10:19 -0000 --Sig_Dl2uozbaUuJiUfGORrLx5z_ Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable On Sun, 31 Dec 2006 19:47:04 +0100 Pav Lucistnik wrote: > Alejandro Pulver p=ED=B9e v ne 31. 12. 2006 v 15:03 -0300: > > On Sun, 31 Dec 2006 18:04:05 +0100 > > Pav Lucistnik wrote: > >=20 > > > Alejandro Pulver p=ED=B9e v ne 31. 12. 2006 v 13:37 -0300: > > > > On Sun, 31 Dec 2006 15:30:29 +0100 > > > > Pav Lucistnik wrote: > > > >=20 > > > > > > - Remove _WX_ILLEGAL_VERS_* added in the last update to 2.8. = The reason is > > > > > > that each port should choose the version it can use, that i= ncludes taking > > > > > > into account available components (also this brings much mo= re chicken and > > > > > > egg problems so the code could get really messy). > > > > >=20 > > > > > I have reverted this. It's needed as long as you want to let peop= le use > > > > > ranges like 2.4+ together with python component, etc. > > > > >=20 > > > >=20 > > > > It is complex to do that (if you want to do it the right way), beca= use > > > > you need to parse components and dependencies before selecting a > > > > version. The current code is wrong since it will only reject compon= ents > > > > without dependency type specifications (and if there were dependenc= ies > > > > then it will also ignore them). > > > >=20 > > > > I think people should select the versions that actually work with t= he > > > > port, that's why the version specification string is so flexible. > > > >=20 > > > > Also, if versions with invalid components are removed then the repo= rted > > > > error if a user writes USE_WX=3D2.4 and WX_COMPS=3Dsvg would be "se= lected a > > > > null or invalid WxWidgets version" instead of "selected a WxWidgets > > > > component (${_WX_COMP}) which is not available for the selected ver= sion > > > > (${_WX_VER})". > > >=20 > > > That can be done, I'm confident. > > >=20 > >=20 > > Yes, but it will remove flexibility in some way: > >=20 > > Currently the version is processed independently from the components. > > The first one is done in or in if > > WX_PREMK is defined (for ports like "x11-toolkits/py-wxPython26"). And > > the second one is always checked in . > >=20 > > If I make the version to depend on the components, then when USE_PREMK > > is defined, the port won't be able to modify WX_COMPS after > > (because the components can alter the version, and if > > then the port will think it's using one, but other will be used). >=20 > Is this the problem with upcoming rollout of bsd.options.mk ? >=20 > I mean, do you need to change WX_COMPS after bsd.port.pre.mk except when > handling OPTIONS and WITH_* flags? >=20 No at least when the port checks variables defined after , like ${ARCH}. Best Regards, Ale --Sig_Dl2uozbaUuJiUfGORrLx5z_ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFmAsCiV05EpRcP2ERAu4FAJkBR/LD7OFpJYRhb2xJtQLe68HlHACgsRFo nUQCooRb8u1X+IAbjNjWHMg= =T2cS -----END PGP SIGNATURE----- --Sig_Dl2uozbaUuJiUfGORrLx5z_--