Re: CHECK_STRUCTS/dmpstruct.h mechanism is broken.

[Achim Gratz <Stromeko@nexgo.de>]

Paul Eggert writes:
> On 4/11/19 12:15 PM, Eli Zaretskii wrote:
>> You want to test for system-dependent features with Make?  How does
>> one do that?
>
> You execute the test as a 'make' rule that records the test's result as
> a makefile snippet (or as a .h file, or whatever).

You'll end up re-implementing years and years of autoconf experience and
probably badly.  We can assume GNU make as long as we keep talking about
make so that will not be quite as painful as it would be otherwise, but
it'd still be an effort I don't quite see as justified.  Lately I've
seen an uptick in "let's build the fastest build system" ideas and all
of them seem to have forgotten that the real work for complex projects
is in configuration.

>> Wouldn't we end up with heaps of Make wizardry only a few understand?
> Sure, just as we now have heaps of .m4 and shell etc. wizardry that only
> a few understand.

M4 syntax is ugly, but it has few enough rules that you can learn and
understand it in an afternoon.  OTOH, quoting and shell-quoting in
Makefiles, not so.

> (Think of it as the law of conservation of wizardry.
> :-) However, an advantage of using Make instead of M4 is that we already
> need to use Make anyway, so avoiding m4 means one less thing for
> developers to learn. Another advantage is that Make can easily run in
> parallel whereas 'configure' does not.

Well, you keep assuming make, but when throwing out so much, why not
throw out the rest as well?  There are many attempts at getting rid of
make out there as well and some of them actually work quite nicely.

> Moreover, Lisp file recompilation is parallelized so it's reasonably
> fast on larger platforms (the wave of the future :-), whereas
> 'configure' will remain slow.

It doesn't have to be.  For starters, checking for all the header files
and libraries could be parallelized easily enough and most of the
configury doesn't actually need to be re-run when any of the configure
options change.  I don't know how active the autoconf project is these
days beyond fixing bugs, but some of it could very well be addressed
with them?


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

DIY Stuff:
http://Synth.Stromeko.net/DIY.html