emacs-devel
[Top][All Lists]
Advanced

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

Re: CHECK_STRUCTS/dmpstruct.h mechanism is broken.


From: Paul Eggert
Subject: Re: CHECK_STRUCTS/dmpstruct.h mechanism is broken.
Date: Thu, 11 Apr 2019 15:23:15 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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

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

> IME, the slowest part is byte compilation of Lisp files.  Of course,
> that is only a significant factor when you bootstrap or rebuild large
> parts of Emacs, but still.
Yes. Typically I don't recompile Lisp files so the bottleneck for me is
'configure'.

Moreover, Lisp file recompilation is parallelized so it's reasonably
fast on larger platforms (the wave of the future :-), whereas
'configure' will remain slow. I just now timed it, and './configure'
took 29 real-time seconds whereas 'cd lisp; make -j16 compile-always'
took 38 real-time seconds; this was with two circa-2013 Xeon E5-2640 v2
CPUs with 8 cores each. So on a 32-core platform, I expect ./configure
to take longer than byte-compiling all the Lisp files - i.e.,
'configure' is ridiculously slow.




reply via email to

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