My periodic bark at auto "tools" 2003/1 edition (was Re:rtems-ss-20030128)

[Joel Sherrill]

Thomas Doerfler wrote:
> 
> Hello Ralf,
> 
> > Am Mon, 2003-02-03 um 16.15 schrieb Thomas Doerfler:
> > > Hello,
> > >
> > > ... 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!
> >
> 
> I confirm with you that there is no general solution to it,
> but we "only" need a solution that works for a certain RTEMS
> snapshot.

I'll go further based up my application support experience.
You only need a toolset that works for a particular application
until that application decides to upgrade.  

The problem is that people grab RTEMS version X and stick with it
as long as they can.  It may be to avoid changes during development,
to keep tight configuration control, or simply because "if it
isn't broke, don't fix it."   

So my perspective is that you don't want N versions of RTEMS and
tools around, you want 1 for each project and 2 during times of
tool upgrades (old/stable and new/to be tested).

This has lead me to install to a PROJECT specific root.  My 
experience is that each project has different timeframes for
upgrades and trying to centrally control them all is a hassle.

And that's if you want multiple projects to share the same machine.
In this day of "cheap machines," I have begun to believe having
a test machine to try out upgrades in parallel is worth it.  

> > >  an aproach of installing a given toolset
> > > (gcc/binutils/newlib/etc...) to something like
> > >
> > > /opt/rtems/gcc-2.95.2-binutils-2.8-newlib-x.y
> > >
> > 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
> > "gcc-2.95.2-binutils-2.13-withoutpthreads-noi18n-nomp-womenonly"
> >
> > As such tuples actually span a multidimensional matrix, you'll very soon
> > get lost in "vector space".
> >
> 
> Hm, I can't quite follow you: As far as I have seen in the
> past, whenever a new RTEMS snapshot was available, there were
> general guidelines saying "The snapshot works with gcc-A.B-C
> and binutils-d.e.f and newlib g.h". No differences between
> BSPs, architectures, used subpackages and so on. So from my
> point of view for each RTEMS snapshot there is ONE recommended
> toolset, and the same toolset might even work for multiple
> snapshots :-).

That's generally the case but the combinatorial explosion is
what Ralf is pointing out.  binutils X.Y might work fine
for 100s of combinations of gcc/newlib/gdb revisions.  The
use of the prefix with the combined name makes every tool
rev, when only one need to.  THis is very important from
my perspective because just doing Linux, Cygwin, and Solaris
hosted binaries independently for binutils, etc. is a lot
of CPU time and disk space to store on the ftp server. 
It factors into more download time for users, etc.

If you want to build them and install them locally using 
an arbitrary naming scheme, go ahead.  But from my
maintainer's perch, I have to satisfy the most users
with the least investment of effort or my family doesn't
see me.

> You know, maybe I have a more "user"-like view to the tools
> than guys like Joel and you, I can guess that you have many
> intermediate toolset versions between snapshots, but most
> users step from one snapshot to the next (even maybe skip some
> snapshots until they want to use new features).
> 
> Another point: whenever somebody mentions the need to install
> multiple toolset versions on the same machine, he/she gets the
> answer "rebuild the toolset with different prefixes", well
> this once again leads to having toolset-dependent installation
> directories, and that's exactly what I would like to have.

You could probably also do some sort of chroot magic but I have
never done that.

> Maybe the naming scheme mentioned above is not the best one,
> maybe it would be better to couple the toolset install
> directory name to the RTMES snapshot version or something like
> that, but I think ANY version-dependent installation dirctory
> in the standard RPMs would be better than the current choices,
> that are:

You are asking me to rebuild every tool with every snapshot.
That simply is not going to happen.  
 
> A:) Install only ONE toolset on a certain machine (and
> deinstall/install another toolset when you switch to a
> different RTEMS snapshot)

This is what OAR does for RTEMS maintenance.

> or
> 
> B:) Rebuild the RPMs (which is really easy, I like it now) and
> apply your own home-brewn naming scheme to the installation
> prefix.



> Any other opinions on this discussion?
> 
> wkr,
>         Thomas.
> 
> P.S.: Ralf, I really want to thank you for the work you do for
> RTEMS, I don't understand all the ideas behind
> autoconf/automake, but I am sure it keeps the RTEMS source
> tree manageable.

I want to thank Ralf again.  It has taken a lot of work over an
extended period of time.

The real issue is that we have slowly migrated to more and
more auto* usage and more and more compliance with GNU standards
so we could integrate better with gcc and friends.  On a postive
note, we have done that with virtually no breakages that have 
gotten into  the world since the first baby steps 
around 4.0.  I think this is amazing. 

But on the negative side, it has taken a nearly continuous 
stream of cautious steps and many, many rebuilds.  All the while
supporting more ports, more BSPs, more functions, and many many
tool upgrades and packaging improvements.

I think RTEMS today is much better tested and more reproducible from
the user's perspective than any time in its history.  I no longer
have to help people build the tools which is a big thing to me.

> --------------------------------------------
> IMD Ingenieurbuero fuer Microcomputertechnik
> Thomas Doerfler           Herbststrasse 8
> D-82178 Puchheim          Germany
> email:    Thomas.Doerfler at imd-systems.de
> PGP public key available at: http://www.imd-
> systems.de/pgp_keys.htm

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985