[Top][All Lists]

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

Re: CHECK_STRUCTS/dmpstruct.h mechanism is broken.

From: Daniel Colascione
Subject: Re: CHECK_STRUCTS/dmpstruct.h mechanism is broken.
Date: Thu, 11 Apr 2019 15:26:25 -0700
User-agent: SquirrelMail/1.4.23 [SVN]

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

caching is supposed to help with that, isn't it?

reply via email to

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