From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7173 invoked from network); 1 Sep 2004 00:51:47 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 1 Sep 2004 00:51:47 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1C2JLm-00076f-Qo for arch-gentoo-dev@lists.gentoo.org; Wed, 01 Sep 2004 00:51:46 +0000 Received: (qmail 31576 invoked by uid 89); 1 Sep 2004 00:51:46 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 734 invoked from network); 1 Sep 2004 00:51:45 +0000 Message-ID: <41351D1D.60207@ifm.liu.se> Date: Wed, 01 Sep 2004 02:51:41 +0200 From: Anton Starikov Reply-To: gentoo-dev@lists.gentoo.org User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040824) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org References: <4134FB0B.9060501@ifm.liu.se> <20040901002625.GA32006@twobit.net> In-Reply-To: <20040901002625.GA32006@twobit.net> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-eltn-site-MailScanner-Information: Please contact the administrator, tel. 2826, for more information X-eltn-site-MailScanner: Found to be clean Subject: Re: [gentoo-dev] per-package environment variables. X-Archives-Salt: d4933ca0-2efb-4df2-8d94-95b1e2afd9d5 X-Archives-Hash: 2f21500ea05d25e772d42938b9bf08d8 Nicholas Jones wrote: >>1) Possibility to change ENV during building some packages. > > > I certainly hope you realize the depths to which people go to > make your life miserable when attempting to do support. Yes :) There is something > The idea is that it takes effort. If it's not trivial, you have to > LEARN to make it work. Having super-easy things is great, but not > when it happens to make FIXING it super complicated, developers lose. Yes, but sollution can be simple...some kind of, probably, limitation applied, at first (for example ONLY env variables, nothing more in this script, onle A=B syntax). And second, idea to get this environment BEFORE something. So, it should be absolutely equal, theoretically, to something like this: CC="bla-bla-bla" CFLAGS="bla-bla-bla" I_WANT_THAT="bla-bla-bla" emerge nice_package I thing that is OK, because anyway users can do it now :) > Some of this might be nice. If you're going to make this kind of > effort, why not integrate it into the ebuild? If I uderstand right, you mean make copy of 10 ebuilds into local overlay and edit them twice a week? When new version of ebuild is coming? :) And in the middle have troubles, because fresh version will be at first automatically updated with standard ENV and at morning I'll reallize that my code don't want to be linked against of library XXX, which was compiled at night with g77 instead ifc or lf95 or pgf90 or something else ? :) That is boring. I've checked already :) >>4) BTW, in such case it also not bad to have option to include something >>like >>USE="ifc" >>into this environment, and it should be parsed in proper way. I hope >>that this is clear. If we want to build something with IFC and set >>proper variables, we really don't want to go and edit one more file >>(/etc/portage/package.use). And we don't want to edit also two files, >>when we will figure out that we like coming gfortran :) > > > Absolutely not. This violates portage's dep calculations and is > completely wrong. Please do not change any variables that are > READONLY inside of ebuild.sh after the depend phase. Again. Idea of this way is to have something equal to CC="bla-bla-bla" CFLAGS="bla-bla-bla" I_WANT_THAT="bla-bla-bla" USE="I_dont_want_that" emerge nice_package This way is OK and works now. Yes, it probably going to be a bit complicated and probably you will need to parse it twice...that is subject of dicussion. > Some of the ideas actually look trackable, which I happen > to like. Inline definitions of variables, I am not > particularly fond of. > > If portage has a way to accurately track these files and > there is a way to avoid arbitary inclusion, then it might > be a lot more feasable. Keep in mind, it was a first iteration :) Not really well designed Just wanted to rise discussion. After which idea could take shape of brilliant :) > Eh. That is all I have to say. > I'm going to go home and take a nap now. :) -- Anton Starikov -- gentoo-dev@gentoo.org mailing list