[Ecls-list] Misc. fixes

[Hannu Koivisto]

Juan Jose Garcia-Ripoll <Juan.Ripoll at mpq.mpg.de> writes:

> Two things here. texi2html is not available everywhere, and the flags

Good point.  Would it be reasonable to find out in configure
whether a suitable texi2html version is available and use it if it
is and fall back to makeinfo if not?  I dislike autoconf and don't
really handle it but I could try to cook some test if that approach
were ok.

> that you provide are not compatible with the version at sourceforge
> (texi2html 1.56k)..

Right, they are for a newer version, at least 1.64 should work.

>>         * src/c/Makefile.in:
>>           * Fixed incorrect suffix rules with pattern rules.
> 
> The suffix rules are not incorrect, AFAIK. Indeed, the pattern rules are

Well, perhaps they aren't with some make implementations, but at
least the dependencies aren't handled properly with GNU make
(parallel builds break; make attempts to use dpp before it is
built).  Even the manual says:

-------------------------------------------------------------------
   Suffix rules cannot have any prerequisites of their own.  If they
have any, they are treated as normal files with funny names, not as
suffix rules.  Thus, the rule:

     .c.o: foo.h
             $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<

tells how to make the file `.c.o' from the prerequisite file `foo.h',
and is not at all like the pattern rule:

     %.o: %.c foo.h
             $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<

which tells how to make `.o' files from `.c' files, and makes all `.o'
files using this pattern rule also depend on `foo.h'.
-------------------------------------------------------------------

It does not seem to be the case (in src/c/Makefile) that make
attemps to create .d.c from $(DPP) and $(HFILES) as the manual
would seem to suggest, but it does not work correctly either.

> incompatible with BSDish makes, like those in FreeBSD, NetBSD, OpenBSD
> and many other unices. Is it really worth breaking compatibility?

Well, in many projects we have concluded it pointless to try to
write portable makefiles and opted to require GNU make as it is so
widely available.

Of course, if portability can be maintained, all the better.
However, in that case I need an alternative, portable fix to the
problem with those rules with GNU make.

-- 
Hannu
Please don't send copies of list mail