Re: [Axiom-developer] Minor bugs

[root]

Bill,

>Tim, please excuse the tone of this reply. I know that
>it sounds rather adversarial. But keep in mind that I am
>writing this while waiting for the 11th repeat of make
>to come back and tell me I left out one more comma or
>another. ...

No problem. I understand the frustrations of making Axiom.
Remember, Axiom used to take 3 weeks to build so life is now sweet.
You DO printout, desk-check, and hand-execute your changes
before you run it, right? (and where is your flowchart?)


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

> For me, mean-time-to-repair is VERY HIGH. 

sigh. we differ on this. but then i wrote it so ....

[.....snip....]

>For the most part the "advanced" features of gmake are
>quite trivial to learn - no more difficult than programming
>in lisp. And if by learning one or two things it is possible
>to reduce 3000 lines of makefile stanzas to just three lines
>that it seems to me that the gain is enormous. Yes it takes
>be a little longer to understand exactly what those 3 lines
>are doing, but when I do it is equivalent to having read
>and understood 3000 lines of other approach.

Clearly this is a question of taste. 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.

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.

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.

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

=======================================================================
ifneq ($(NIFLAGS),)
new_init.o: new_init.c $(DECL)
        $(CC) -c $(NIFLAGS) $(DEFS) $< -o $@
endif


=======================================================================
        cd $(@D) && rm -f *.o rt/*.o && echo '(load "gclload.lsp")' | ../$< 
>$(@F) 2>&1 & j=$$! ; \

=======================================================================
        GCLDIR=`echo $(GCLDIR) | sed -e 'sX^/cygdrive/\([a-z]\)X\1!Xg' -e 
'sX^//\([a-z]\)X\1!Xg'` ; \

=======================================================================
        $(CC) -DNO_DEFUN $(CFLAGS) $(DEFS) -E $*.c | sed -e 's:\"[ ]*):\"):g' | 
./grab_defs > $*.ini
        nm $< | awk '/ U / {a=$$2;if (k) sub("^_","",a);\
                            b=a;gsub("_","",b);\
                            if (match(j,b)) printf("MY_PLT(%s)\n",a)}' \
                        j="$$(awk '/main/ {i=1;next} {if (!i) next} \
                                /^ *[a-zA-Z_]*\(/ {sub("\\(.*$$","",$$1);print 
$$1}' plttest.c)" \
                        k=$(LEADING_UNDERSCORE) |\
                        sort | \
                        awk '{A[++k]=$$0} END {for (i=1;i<=k;i++) \
                                printf("%s%s\n",A[i],i==k ? "" : ",");}' >$@

=======================================================================

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

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.

Tim