3.0alpha24: make bug (or more...)

[David Lee]

On Fri, 16 May 2003, Andrew Bartlett wrote:

> I'm not fussed on this bit - just don't jump thought hoops to include
> build_options.c.  Instead patch includes.h to include that particular
> prototype.
>
> This should result in a simpler patch.

Thanks.

(STOP PRESS:  STOP PRESS: I have discovered a minor weakness of a detail
in my patch. The detail is irrelevant to what follows, but needs to be
corrected before the patch is applied.  Its "sed ... '/.../.../'" should
be "sed ... ,...,...,".)

I take your point.  (Are you ready for the inevitable "but"?...)

But... "mkproto.sh" was already inherently flawed: Vance's build_options.c
has simply exposed its pre-existing weakness.  My patch fixes this
structural weakness.  Surely a good thing?  (And, as a mere side-effect,
it allows "build_options.c" to find its way, automatically and
maintainably, into "proto.h".)

So what is the inherent structural weakness in mkproto.sh which I allege?
(Forget "build_options.c" for the moment).  Imagine it as a black box.
Its purpose is to obtain subroutine definitions from a list of files.
But the list of files supplied is object files!  Surely this is, ahem,
less than ideal.  So it first had to back-translate the ".o" into ".c".

Further: "mkproto.sh" seemed unclear in its own mind which of its files
(supplied, builtin and output) were relative to make's $(srcdir) and which
to $(builddir).  It included a mixture of them and seemed based on some
unclear assumptions.


The main element of my patch (although perhaps I failed to draw your
attention explicitly to it) was that it cleaned up this interface.
"mkproto.sh", whose primary job is to read *source* (.c) files was having
to not being given the necessary ".c" information, was was having to
attempt to second-guess it from suboptimal ".o" information.

Re-read my patch with this in mind:  Its purpose is to clean up the
interface from "Makefile.in" to "mkproto.sh", supplying it with the
appropriate ".c", rather than the inappropriate ".o" files.  A cleaner and
stronger structure.  Full stop.  That's it. Nothing more.

(Oh, and by the way, now that it cleanly uses ".c" rather than ".o", then
"build_options.c" is cleanly and automatically catered for: icing on the
cake.)



-- 

:  David Lee                                I.T. Service          :
:  Systems Programmer                       Computer Centre       :
:                                           University of Durham  :
:  http://www.dur.ac.uk/t.d.lee/            South Road            :
:                                           Durham                :
:  Phone: +44 191 334 2752                  U.K.                  :