new Makefiles was Re: RTEMS 4.6.2 BSP support

[Ralf Corsepius]

On Fri, 2004-10-22 at 18:52, Chris Caudle wrote:
> Joel Sherrill wrote:
> > At this point, there have been mostly changes to:
> >
> >   + reduce Makefiles from ~1400 -> ~400
> 
> Are any of the maintainers familar with the paper that came out a few
> years ago recomending include files that pull all the make information
> into a single top level make file, instead of make files in each
> directory that are processed recursively?

I am. I read this paper several times, many years ago ;-)

> The abstract is here:
> http://www.tip.net.au/~millerp/rmch/recu-make-cons-harm.html
>
> and the actual paper is here:
> http://aegis.sourceforge.net/auug97.pdf

My opinion about this paper is ambivalent. 
I consider it as "worth reading", but also as vastly overrated.

> Any comments on whether this would be a useful goal for RTEMS, and if
> useful, practical?
Let me put it this way: To some extend, implementing "flat Makefiles" is
helpful, but as soon as complexity of a source tree grows, this
philosophy reaches its practical limits.

>   I have heard commentary elsewhere that the philosophy propounded in
> the paper does not play well with autoconf. 

Well, not quite. The problem had been automake, which had not been able
to handle deep source trees in single Makefiles. Meanwhile (the paper is
dated from 97!), automake has been extend and is able to handle deep
source trees.


>  I'm not familiar enough with autoconf to know whether that is a valid
> concern or not.

IMO, this is not necessarily an issue with the autotools, but a general
flaw, defect or whatever you want to call it, in the basics of this
approach/philosophy.

In particular, the author neglects the aspect of using subdir Makefiles
(Makefile-hierarchies) as means to structurization, modularization and
reduction of complexity of Makefiles.


If you have a look at what happened to RTEMS's Makefiles between
rtems-4.5 and current CVS-trunk, you will notice that I implemented flat
Makefiles for subtrees of the source-tree, i.e. I tried to find a
compromise between "flat", "modularization" and "complexity".

This is where the reduction in the number of Makefiles comes from. E.g.
each BSP now has one configure script and one Makefile (i.e. each BSP
has a flat Makefile).

Ralf