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

[Ralf Corsepius]

Am Fre, 2003-01-31 um 21.29 schrieb Till Straumann: 
> Hi all.
> > 
> > 
> > Sorry guys.  I used a very poor choice of word.  I really believe in
> > automake and autoconf and am glad that RTEMS is using it.  
> > 
> 
> Well, I dont. And I'm sad RTEMS is using it.
Well, lack of insight, I would conclude/presume ;)

(No personal insult/offense intended)

>  Here is my latest story:
>
> Our current RTEMS version is ss-20020301. I'm planning to upgrade to
> the upcoming (?) new release, however and so I am playing around with
> ss-20030128. Since there are several developers involved and a lot of
> software on top of RTEMS, I need to support two versions of RTEMS at
> a time during the migration phase.
> 
> 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.

> 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.

> After some frustrating research I found that the new "auto" "tools"
> do _not_ work with the old snapshot. 
Yes, they don't, nor does an older gcc, nor newlib.

This also applies to Linux and most other operating systems: 
Your toolchain must match the kernel, the libc and further requirements.

This is not any different from the situtation on other OSes: Certain
versions of the linux kernel do not compile with certain gcc's, certain
glibc's are incompatible to certain gcc's and so on.


> Wonderful [and besides, I don't
> want to read a FManual unless I need to write a Makefile.am, I just
> want to run 'bootstrap'].
You can't be serious. You want to work on a system and do not want to
learn the tools you are using?

You never read a gcc-manual, nor cpu-manual, nor asm-manual. 

For using autotools with RTEMS it would be sufficient to have understood
the very basic working principles of the autotools and to compare your
stuff to similar BSPs in the official sources.

> 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)

* 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. 

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.

> 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 ...

> 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 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.

Ralf