| raw e-mail | index | archive | help
--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 <pav@FreeBSD.org> 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 <pav@FreeBSD.org> 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 <pav@FreeBSD.org> 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 <bsd.port.post.mk> or in <bsd.port.pre.mk> if
> > WX_PREMK is defined (for ports like "x11-toolkits/py-wxPython26"). And
> > the second one is always checked in <bsd.port.post.mk>.
> >=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
> > <bsd.port.pre.mk> (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
<bsd.port.pre.mk>, 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_--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?>