Re: CHECK_STRUCTS/dmpstruct.h mechanism is broken.

[Achim Gratz <Stromeko@nexgo.de>]

Paul Eggert writes:
> Achim Gratz wrote:
>> You'll end up re-implementing years and years of autoconf experience and
>> probably badly.
>
> The "years and years" of experience you're taking about is experience
> that is under my belt. I have been a reasonably major contributor to
> Autoconf and to all the Emacs configury code and I know how it
> works. I would not reimplement it badly.

I didn't mean to imply you would personally re-implement it.  I'm well
aware of your involvement with gnulib and autoconf.

By "badly" I meant that there will be a (likely extended) period of
transistion where things that used to work with autoconf don't work (at
all or breaking in more subtle ways) with whatever the new system is.
That'll grow resentment towards the new system as history with other
such attempts (re-implementing make, anyone?) has shown.

"The Perfect Should Not Have Grown"
  (F. Nietzschein "Human, all too Human", transl. by H. Zimmern)

"Das Vollkommene soll nicht geworden sein."
  (F. Nietzsche in "Menschliches, Allzumenschliches")

> The idea I have is basically the idea that you proposed in another
> email: do the obvious parallelizations with the current
> recipes. However, doing this under the aegis of Autoconf would be a
> mistake. Autoconf is essentially unmaintained now, and for good
> reason: it's a dead-end and nobody wants to deal with it.

Well, I feel towards autoconf like that old quip about democracy: it's
the worst form of configuring your project, except for all the others.
As for it being a dead-end: show me another project that even approaches
the same breadth and depth on _configuration_ and I'll reconsider.

> We should be looking at migrating its good stuff (mostly shell+m4
> recipes) to a better framework.

(Not sure what exactly you mean by framework here.  I'm assuming you
meant "something like autoconf", but different.)

The existing build systems or build system generators (as far as I spent
time looking at them) don't seem to fit the bill, so we'd either have to
find something more suitable (why didn't we hear about it already?) or
pony up for something entirely new.  I still think that incrementally
improving autoconf is more likely to successfully (and quickly) move
things forward than trying to outright re-implement it.

Another consideration for Emacs specifically would be how much extra
baggage we can afford to pack and still support all the systems that we
do now.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada