From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16132 invoked from network); 31 Aug 2004 22:26:25 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 31 Aug 2004 22:26:25 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1C2H56-0007Su-V4 for arch-gentoo-dev@lists.gentoo.org; Tue, 31 Aug 2004 22:26:25 +0000 Received: (qmail 26222 invoked by uid 89); 31 Aug 2004 22:26:24 +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 18766 invoked from network); 31 Aug 2004 22:26:23 +0000 Message-ID: <4134FB0B.9060501@ifm.liu.se> Date: Wed, 01 Sep 2004 00:26:19 +0200 From: Antst GD 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 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: [gentoo-dev] per-package environment variables. X-Archives-Salt: 5a89f9fe-af91-40a3-a50d-b05d13cc7609 X-Archives-Hash: 4188b19bac94cb1c320810d670da28fb OK, lets develop discussion about option to choose environment variables per-package (compiler, flags and not only). As some of us know, definition of problem already include 90% solution. So, lets start from user-side. Want we want to see? 1) Possibility to change ENV during building some packages. 2) it should be automatic, no more definition of environment variables and manual emerging packages. No more spaming /etc/make.conf with some environment variables which correspond only to one package (RXVT_TERM, for example) 3) Solution must be flexible and allow us to have not only "per-package" variables set, but also define some general sets for inclusion. For example if we want to build soft1,soft2,ans soft3 with IFC, we really don't want to have 3 copies of something like: F77=ifc FC=ifc F90=ifc FFLAGS="-xN -ip" Moreover, when we will decide to change CPU, we will not need to edit 3 files and change -xN to -xP. We want to do it once. :) 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 :) 5) even more. I'll start not with per-package basic, but with per-environment basic, as a first iteration. So, lets define our problem in more details: 1) Assume that default configuration of my system is GCC 3.4.1 CFLAGS="-O2 -pipe" in /etc/make.conf LINGUAS="ru" in /etc/make.conf there is no defined ifc and icc USE flags in /etc/make.conf 2) I have set of packages, that require something "extra" lam-mpi : want to compile with ICC, IFC blas-reference : want to compile with g77 and high optimization lapack-reference : want to compile with g77 and high optimization blas-atlas: want to compile with IFC, ICC lapack-atlas: want to compile with IFC, ICC xine-lib : want to compile with low-optimization for GCC open office : want to compile with LANGUAGE="RUSS" and GCC 3.3.4 and low-optimization kde-i18n : want to have with LINGUAS="fr" and GCC 3.3.4 rxvt : want to compile with RXVT_TERM=xterm octave : want to build with high-optimization for GCC so, what I see? Something like: #cat /etc/portage/package.env lam-mpi: icc ifc blas-reference: g77high.env lapack-reference: g77high.env blas-atlas: ifc.env icc.env lapack-atlas: ifc.env icc.env xine-lib: GCC_lowopt.env openoffice: language_ru.env GCC_334.env GCC_lowopt.env kde-i18n: linguas_fr.env rxvt: rxvt.env octave: GCC_highopt.env #ls /etc/portage/env ifc.env ifc.env GCC_highopt.env GCC_lowopt.env rxvt.env linguas_fr.env language_ru.env GCC_334.env g77high.env and #cat /etc/portage/env/icc.env CC=icc CXX=icc CFLAGS="-O2 -xN -noalign" CXXFLAGS=$CFLAGS USE="icc" #cat /etc/portage/env/GCC_highopt.env CFLAGS="-O3 -ffast-math -funroll-all-loops -fmove-all-movables" #cat /etc/portage/env/GCC_lowopt.env CFLAGS="-O1" #cat /etc/portage/env/GCC_334.env CC=/usr/i686-pc-linux-gnu/gcc-bin/3.3/gcc g77=/usr/i686-pc-linux-gnu/gcc-bin/3.3/g77 And rest it similar. Of course, it could be not so bad, to have option, to include name of file with ENV, or just env, to not produce tens of files with one variable, like RXVT_TERM="xterm"... There is seems to be two solutions: 1) just have second file with definitions, where not filenames, but defined variables. 2) change syntax of /etc/portage/package.env in such way, that allow to include both kind of records, filename and strict definition inline. something like openoffice: GCC_334.env GCC_lowopt.env -- LANGUAGE="RUSS" For the moment both solutions looks ugly for me. At least I can't imaging simple and easy-to-understand syntax for package.env, which will look nice and will parce without problems. What do you think about? -- Anton Starikov -- gentoo-dev@gentoo.org mailing list