[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Axiom-developer] Minor bugs

From: Bill Page
Subject: RE: [Axiom-developer] Minor bugs
Date: Sun, 19 Dec 2004 22:36:18 -0500


Shortly after my last message I did (finally) manage to
get a clean build. But I can't help but feel like there
must still be some "loose wires" in the
src/input/Makefile.pamphlet because I kept having to
repair things that I never changed. For example make
suddenly started complaining about a file named
XPOLY.output (no rule for target), it occurs in the list
named OUTS but sure enough I can't find any stanza and I
certainly didn't add anything with that name. There are
other stanzas for xpoly.input etc., but nothing with
uppercase names. I just commented it out and the build
worked. Weird.

On Sunday, December 19, 2004 5:19 PM you wrote:

> ...
> Remember, Axiom used to take 3 weeks to build so life
> is now sweet.

Ah, the pleasures of talking with the old-timers ... <grin>

> You DO printout, desk-check, and hand-execute your changes
> before you run it, right? (and where is your flowchart?)

Why, yes. Of course. (flow what? oh, you mean like those
complex pictures they draw in UML, I guess ... I thought
nobody did that until Rational invented it back in the
90's ;)

Actually, I started programming in 1970 so I do have
some grey hair and a few stories to tell myself. The
trouble is, machines are enormously faster - that's
nice, but people are just as slow as ever.

> >But there is a lot of regression stuff in the
> >
> > src/input/Makefile.pamphlet
> >
> >that is trying to run every time I do a build ...
> Actually, that's only the input to the regression
> mechanism which is yet to be recovered.

Then what exactly is "Daly bug"?

> > For me, mean-time-to-repair is VERY HIGH. 
> sigh. we differ on this. but then i wrote it so ....
> ...
> It appears that you view 'make' as a programming language
> and I view 'make' as a list of commands. I fear the
> "slippery slope" of using gmake features.

No, I do not think 'make' is either of these. When used
properly a Makefile is just an abstract specification of
the dependency relationships between objects mapped to
associated concrete actions that implement those dependencies.
There should be no procedural programming in a make file at
all. The goal of 'make' is to allow the programmer to work
at a higher level of abstraction, knowing that for each
change to the objects she makes, 'make' will convert her
specification into a minimum set of actions to take on all
the related objects that are necessary in order to satisfy
the dependencies.

Actually this very likely has a nice tidy formal description
as an adjoint functor on some category or other, I am sure.
But that is another story.

> It's been my experience that any project that starts down
> that path eventually heads toward ever-more-clever makefiles.
> Witness the patch that we do to GCL. Neither you nor I know
> what the sed script does that mangles lists of filenames.
> Programmers simply cannot resist features.

This has nothing to do with 'make' as such. But yes, on first
examination I do find the GCL makefiles largely unintelligible.
Certainly in part this is because of the use of "clever hacks"
such as the one you mention. But in most cases I think you
will probably discover that such obscure coding is forced
on the programmer by a number of other circumstances some
of which are beyond their direct control. Usually this has
a lot to do with the lack of standards. I think this problem
is gradually, with the rise of the Internet and open source
development we are at last we are learning to appreciate the
value of standards.

> Makefiles that use "advanced features" (like if blocks,
> gcl -MM,includes, sed-built file lists, dynamic stanza
> loading, etc) quickly change 'make' into yet-another-
> programming-language.

Again, when used properly these things should be just short-
cuts for specifying a large number of complex dependencies
in a simple manner. Often this takes for form of a kind of
"2nd order" program whose output is the specification of some
dependencies. I agree that sometimes the methods for specifying
these dependencies that is chosen by the designer of a makefile
can be as obscure and poorly documented as any other programming

> I can read (and program) complex makefiles. I just don't
> want to write a program in a language consisting mostly
> of line-noise. The rule-based programming feature of make
> (a DEPENDS-ON b) is useful for minimizing work redone but
> the rest of the features are truly bad language design.
> This might as well be APL code.

I agree with you (except for the slur against APL :). But I
think that it is possible to write efficient makefiles, i.e.
short and relatively simple, makefiles without such "line noise".
Such obscure notation for make specifications is usually just
expedient, poorly thought out design that turns to stone when
it cannot be maintained. It is possible to write obscure
programs in almost any language. And unix shell script is
one of the easiest in which to do this.

> I find these examples (taken from real makefiles at random) 
> hard to read:
> ==============================================================
> =========
> OOBJS:=$(shell j=$$(ar t $(ODIR)/gcllib.a) ; for i in $$(ls 
> -1 $(ODIR)/*.o) ; do if ! echo $$j |grep $$(basename $$i) 
> >/dev/null 2>&1 ; then echo $$i ; fi ; done)

This one appears complex precisely because of the shell script.
This is not make's fault, it is the fault of the programmer
who choose to use these commands. But this is actually
not so hard to understand if you understand the unix tools
and filters that are being used.

I think most of your other examples are similar

> ...
> ==============================================================
> Makefiles, for me, are just a record of the correct sequence
> of lists of commands needed to build a system. Isn't this
> simple?

No. If that is all that make was, then why not simply write
out that sequence of commands and stop messing around with

> I agree that implicit stanzas shorten the makefiles and would
> reduce the clutter and size of the makefile. Provided the
> implicit stanza was generic enough to work in both make and
> gmake it might be ok. They "break" two design points:
> stanza-per-file and unique echo numbering. However, I'm more
> willing now to reconsider implicit stanzas if only to concede
> to a meet-in-the-middle compromise.

Implicit stanzas are another way of providing a large number
of specifications in an economical manner but they can only
be used to specify very simple relationships. Still, I agree
that a few carefully chosen implicit stanzas would go a
long way to reducing the sheer bulk of the current Axiom

Yes, I like meet-in-the-middle compromises. Isn't that
one way to help make a marriage last a little longer. :)

Bill Page.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]