[RFC] build system replacement

[Denys Vlasenko]

On Saturday 31 May 2008 13:55, Bernd Schmidt wrote:
> Denys Vlasenko wrote:
> > As I said, I am not obsessed with build system replacement.
> > I started it as a necessity because I was bitten several times with
> > the modification of files not being detected.
> > 
> > I thought that it is a sign that build system is not maintained
> > and is bit rotting.
> > 
> > After recent events (your fix and my testing) I now see that
> > 
> > 1. There are people (you) who understand and maintain
> >    current build system;
> 
> I wouldn't go that far.  It's just that whenever I've had to look at it 
> I've found it quite easy to work with - there are much worse ones out 
> there (cough glibc cough).

It seems to be based on Linux kernel one, from five years ago or so.
It looks not so bad as these systems go, but Linux kernel build system
has improved since then.

> My point is simply that being able to  
> understand and modify existing code is a necessity;

Absolutely. However, there is a flip side of it - the code should aim
at being understandable (by people somewhat less clever than
the creator of the code).

   Everyone knows that debugging is twice as hard as writing
   a program in the first place. So if you're as clever
   as you can be when you write it, how will you ever debug it?
        * Brian Kernighan, "The Elements of Programming Style",
          2nd edition, chapter 2

I would fix the system which I can understand. Current one
is a bit above my abilities to do so. If only it had a bit
of documentation, let's say, in a form of inline comments
in makefiles... grep says that most of comments
are in the first few lines of a Makefile.
I.e. these are copyright headers, not docs.

> a rewrite from  
> scratch is likely to introduce more problems in the short term than it 
> can solve.
> 
> > 2. The breakage is not as widespread as I thought - actually,
> >    all .c files are properly tracked. Or almost all -
> >    I did not check all possibilities, maybe there are a few more
> >    obscure .config's with problems.
> > 
> >> Adding header file dependencies would be a good thing.  IMO, if it can 
> >> be done within the existing framework, that's better than throwing 
> >> everything out.
> > 
> > Are you willing to look into it?
> 
> I'm not really a make expert, and I didn't intend to become maintainer 
> when I submitted a patch...

Is there a maintainer of it? If not, is anyone willing to become one?

> The patch below copies over just enough parts of the glibc dependency 
> system to make it work on simple cases in uClibc (tested by touching 
> include/mntent.h and watching it rebuild only five files).  It's 
> probably uglier and less efficient than it needs to be; I doubt it 
> tracks all object files, and it doesn't integrate with "make clean".

"compile-mkdep-flags" variable is used exactly in one place.
It's not clear to the casual reader why you want it to be
a separate variable.

+depfiles := ...

A variable with '+' in name? Well, yes, make allows even this,
but is there a reason for it? Reader gets confused again...

> Finishing the job is left as an exercise for the reader :-)
--
vda