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

[Joel Sherrill]

Ralf Corsepius wrote:
> 
> Am Fre, 2003-01-31 um 21.29 schrieb Till Straumann:

> > Needless to say that I again had to upgrade to the latest cutting edge
> > version of the auto "tools" (Again, the versions mentioned by
> > README.configure were not enough).
> Please, report such kind of issues. I don't recall having seen any bug
> report related to this, neither from anybody nor from you.

Please do report these.  It is very easy to let a README slip out of 
date.  This is one of the reasons I added the generation of the file
"TOOL_VERSIONS" to the cut_release script.  If nothing else, it 
records some configuration information on the build environment in which
the tarball was tested.  In includes the definitive word on what
auto*, gcc, newlib, gdb, and binutils were used as well as the host OS 
version.  That doesn't mean that one can't go forward or backwards a bit
in version numbers or patches but it isn't guaranteed.
 
> > OK, I upgrade those fabulous "tools" (and after upgrading the compiler
> > etc. as well), I built the new snapshot.
> 
> > To my great surprise, however, I suddenly got obscure errors when
> > re-'make'ing the old RTEMS version (using the old compiler, of course)
> Well, you are experiencing gcc/newlib/sourcetree changes.

Unfortunately, the cost of progress. 


> > Along with RTEMS, I now need to maintain two versions of automake, of
> > autoconf + two versions of gcc + newlib etc.
> > Note that I have to rebuild all of these from scratch because I
> > cannot install two RPM versions simultaneously :-( :-(.
> 
> Possible solutions:
> 
> * 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.

> * Install 2 versions to different prefixes.
> 
> > Will there be any point in the near future when you can
> > freeze the autotool requirements to some decent version
> You are missing one important point: You have been using comparatively
> volatile "development snapshots" not a "frozen product".
> 
> > (e.g. one that's already shipped with an off-the shelf
> > linux distro)?
> Well, there is no "official" nor "standard", not even an "industrial
> standard" Linux to rely upon.
> 
> And even if there were one, it doesn't necessarily mean that these
> vendor's products and these products' components are applicable.
> 
> RTEMS configuration and building primarily is complex due to the nature
> of the problems, not due to the tools being used.
> Therefore, building RTEMS triggers all kind of issues in a wide variety
> of tools, with gcc, binutils and autotools being prominently exposed
> victims.

That's a very polite way of saying it. :)  

Putting a positive spin on it, the RTEMS community has gotten a good
reputation for reporting real bug/problems and they generally get fixed
in a timely manner.  

> As a consequence of this, we (primarily Joel and me) fairly frequently
> encounter problems nobody else seems to have encountered before and try
> to get them fixed - Result: they often get fixed in newer releases of
> the tools => Therefore, in many cases a new RTEMS release often requires
> a newer toolset.

For example, newlib 1.11.0 was pretty close to patch free and gcc 3.2.2
will
be within a 1 line patch of having all known RTEMS target problems
resolved.

> > I also would be helpful (this has been discussed) to be reluctant
> > to changes to the RTEMS/newlib interface in order for being able
> > to re-use a xgcc/newlib installation for multiple snapshots.
> Yes, I basically agree, but .. reality is different .. the situation in
> the past was plain broken, the situation now is significantly better,
> but still far from being perfect ...

We are reluctant to make those changes.  The past two large changes to
the
interface were to 

  + move pthread.h to newlib so gcc could be built with multithread
library
    support.  (the post 4.5 compatbility break)
  + reduce the number of RTEMS specific .h files in the newlib 
    source.  We had complete duplicates of at least 6 files 
    and the maintenance was not pleasant.  

Other changes have been relatively minor in comparison.  For example,
Eric Norum reallocated the signals so the set required by EPICS would
be included.  

> > E.g. cut releases more often but allow gcc/newlib changes only
> > when changing the minor version number.
> Fully agreed. I don't recall how many times I said something similar.

I wish it were easy to control these more but in the interest of having
the most perfect toolset out there, bugs have to be fixed.

> > I do not want to offend anyone and I appreciate your great
> > work - it's just that autoxxx frustrates me so often when I
> > try to get my work done.
> 
> Well, I can relate (I have been struggling with the auto*tools
> maintainer more than once), but with current auto*tools, the situation
> actually has improved much. autoconf-2.57+automake-1.7.2 is a much more
> mighter toolset than they have ever been before.

And I have been making progress on the newlib/gcc front.  The fewer
patches
we have to the vanilla distribution, the less likely it is that point
revisions
are required for RTEMS specifically.


> Ralf

--joel