[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
My periodic bark at auto "tools" 2003/1 edition (was Re:rtems-ss-20030128)
- Date: 03 Feb 2003 17:58:46 +0100
- From: corsepiu at faw.uni-ulm.de (Ralf Corsepius)
- Subject: My periodic bark at auto "tools" 2003/1 edition (was Re:rtems-ss-20030128)
Am Mon, 2003-02-03 um 16.15 schrieb Thomas Doerfler:
> ... many lines snipped...
> > >
> > > * Rebuild the rpms from source and edit the rpm.specs on your demands.
> > > (This typically means to change the package names and the prefix - and
> > > to read the manual of another tool: rpm)
> > We have considered building release tools to install into a separate
> > $prefix from snapshots. Something like /opt/rtems-4.6 instead of
> > /opt/rtems. This doesn't solve your immediate problem but distinguishes
> > release branch tools from development branch ones.
> years ago there was
Here, you say it "was". It simply doesn't work!
> an aproach of installing a given toolset
> (gcc/binutils/newlib/etc...) to something like
> Whenever you wanted to work with a given project and RTEMS
> snapshot, the only thing to do was to include the
> corresponding path into your PATH environment. I really like
> this way of tool installation, because then each user can
> select, which toolset is to be used for his project. This is
> more or less the only way I know to install various toolset
> versions on one machine.
> Unfortunately the standard RPMs now come without that
> installation prefix, I never quite made out why.
Quite simple, this form of "canonicalization" is subject to the
"Symbol-Grounding-Problem", as AI calls it.
It tries to apply a classification into certain categories.
At the beginning such attempts look promising, but at some point later,
somebody will be asking for addition or removal of a new category.
Very soon you'll end up with
As such tuples actually span a multidimensional matrix, you'll very soon
get lost in "vector space".
Side effect: You won't be able to upgrade on of the components you are
using, even if this component would be compatible (eg. you would not be
able to upgrade to binutils-2.14, even if they were compatible).
> Wouldn't it solve many problems to go back to that LONG
> installation prefix in the standard RPMs?
I think we should go the way Joel brought up.