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: [gentoo-dev] per-package environment variables.
Date: Wed, 01 Sep 2004 00:26:19 +0200	[thread overview]
Message-ID: <4134FB0B.9060501@ifm.liu.se> (raw)

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


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

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-31 22:26 Antst GD [this message]
2004-08-31 22:34 ` [gentoo-dev] per-package environment variables Mike Frysinger
2004-08-31 22:44 ` Antst GD
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=4134FB0B.9060501@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