From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.43) id 1DoOgn-0005hx-1J for garchives@archives.gentoo.org; Fri, 01 Jul 2005 16:48:29 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j61Gls0S022526; Fri, 1 Jul 2005 16:47:54 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j61GlsfL020011 for ; Fri, 1 Jul 2005 16:47:54 GMT Received: from adsl-67-39-48-193.dsl.milwwi.ameritech.net ([67.39.48.193] helo=exodus) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1DoOgD-0003NC-Ja for gentoo-portage-dev@lists.gentoo.org; Fri, 01 Jul 2005 16:47:53 +0000 Date: Fri, 1 Jul 2005 11:47:55 -0500 From: "Brian D. Harring" To: gentoo-portage-dev@lists.gentoo.org Subject: [gentoo-portage-dev] splitting build deps out from depends Message-ID: <20050701164755.GC11634@exodus.wit.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="61jdw2sOBCFtR2d/" Content-Disposition: inline User-Agent: Mutt/1.5.8i X-Archives-Salt: 76dd838a-c908-43c2-b326-b5e27a8cdd25 X-Archives-Hash: ffb32484b8a35b91a7591320dd32b10b --61jdw2sOBCFtR2d/ Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hola. Quick statement of terminology-=20 x-compile =3D=3D cross compiling, building arm crap on an x86, building up= =20 a x-compile target in a subdirectory of / (fex) Currently, we pretty much leave out the big dogs of build depends from=20 ebuilds- basically we rely on the profile to require a suitable=20 toolchain. Couple of issues with this though- 1) Deps aren't complete for an ebuild. 2) Merging a php or python lib that doesn't require compilation=20 doesn't require a full toolchain, distutils/pear or make mainly. =20 So autoassuming a c/c++ toolchain is required isn't accurate. 3) For automatically handling x-compile deps, without this info bound=20 to an ebuild, portage will _never_ be able to know what=20 dependencies are x-compile targets, and what deps must be natively=20 merged. So... why don't we add a new DEPEND, BDEPEND (build depends), that=20 holds atoms of what is required to actually build the package,=20 literally, what executes on the box to build that package. Still would have DEPEND, since (using diffball as an example) building=20 it doesn't execute anything from bzip2/libz, it just builds against=20 those atoms. Aside from the goal of having complete dependencies, BDEPEND can be=20 used by portage to know what needs to be built native to that box, vs=20 what is an x-compiled dependency. So... we could actually do a full=20 stategraph covering x-compile deps, and the actual x-compile=20 toolchain. Thing is, it's an extra bit ebuild devs have to deal with. So get out=20 your pitchforks/torches and throw in your two cents on the extra bit=20 of effort required from ebuild devs. In the circles where this idea=20 developed in, it solves some nasty portage issues (iow, it's useful to=20 us for addressing a hard problem and supplying further functionality). Re: backwards compatibility, profile's holding the toolchain pretty=20 much covers up the fact BDEPEND is missing from the tree; it's a non=20 issue, only an issue if you're cross compiling (spanky's x-compile=20 work mostly gets around this afaik, although it's something of abuse=20 of portage), or if your profile doesn't specify a full toolchain. In other words, those who fall into the two scenarios above are=20 already dealing with this issue, so there really isn't a concern of=20 backwards compatibility. Either way, kindly chuck in your two cents (preferably on -dev ml,=20 since this is cross posted). ~harring --61jdw2sOBCFtR2d/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCxXO7vdBxRoA3VU0RAunQAJ95YgUNOX5Hix8Dhrer6dNkE7JWlQCgm/BU BobIajFlBxC4QcagSgQqODk= =F9vt -----END PGP SIGNATURE----- --61jdw2sOBCFtR2d/-- -- gentoo-portage-dev@gentoo.org mailing list