public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Antst GD <antst@ifm.liu.se>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] per-package environment variables.
Date: Wed, 01 Sep 2004 00:44:47 +0200	[thread overview]
Message-ID: <4134FF5F.4050001@ifm.liu.se> (raw)
In-Reply-To: <4134FB0B.9060501@ifm.liu.se>

I've checked /usr/lib/portage/pym/portage.py
With minor changes, this is is extremely easy to add provided syntax to 
current portage. Just about 5 lines of code. :)
I can make a patch, people who interesting can try to use it as a 
testers  :)


Antst GD wrote:
> 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


  parent reply	other threads:[~2004-08-31 22:45 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-31 22:26 [gentoo-dev] per-package environment variables Antst GD
2004-08-31 22:34 ` Mike Frysinger
2004-08-31 22:44 ` Antst GD [this message]
2004-09-08 18:19   ` Ned Ludd
2004-08-31 23:28 ` Mike Frysinger
2004-09-01  0:00   ` Anton Starikov
2004-09-01  0:13   ` Anton Starikov
2004-09-01  3:05   ` Olivier Fisette
2004-09-01 11:08     ` Anton Starikov
2004-09-01 15:53       ` Robin H. Johnson
2004-09-01 19:56       ` Olivier Fisette
2004-09-01 22:39         ` Anton Starikov
2004-09-02 22:49         ` Anton Starikov
2004-09-02 23:30           ` Olivier Fisette
2004-09-03  1:36             ` Anton Starikov
2004-09-03  1:35               ` Robin H. Johnson
2004-09-03  2:05               ` Olivier Fisette
2004-09-03  2:53                 ` Anton Starikov
2004-09-01  0:26 ` Nicholas Jones
2004-09-01  0:51   ` Anton Starikov
2004-09-01 14:02 ` aye
2004-09-01 14:22   ` Anton Starikov
2004-09-01 15:59   ` Robin H. Johnson
2004-09-01 18:42     ` aye
2004-09-01 18:46       ` Robin H. Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4134FF5F.4050001@ifm.liu.se \
    --to=antst@ifm.liu.se \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox