|
|
Subscribe / Log in / New account

configure once, compile many times

configure once, compile many times

Posted Apr 29, 2025 16:35 UTC (Tue) by marcH (subscriber, #57642)
Parent article: Barnes: Parallel ./configure

I think this common design "pattern" is based on the assumption that developers configure "once" and then compile many times? Obviously wrong for automation now.

Can't hurt for sure.


to post comments

configure once, compile many times

Posted Apr 30, 2025 9:54 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (3 responses)

It doesn't help that configure is traditionally a shell script. The POSIX-compatible subset of the shell has no lighter-weight parallelism facility than spawning an entire process, with all of the usual problems that implies. Probably nobody thought it was worth it, before 24-core systems became a thing that normal people had on their desks.

configure once, compile many times

Posted Apr 30, 2025 10:26 UTC (Wed) by jengelh (guest, #33263) [Link] (2 responses)

When you have 24 threads, just run 24 configures (for different build types, different packages), problem solved ;-)

Also, with many platforms and (non-)standards having fallen out of fashion in the last two decades, a lot of tests are also more or less obsolete in the sense that one's configure.ac need not invoke them any more, like

$CC not supporting -o
ANSI C prototype support
Support for keywords "inline", "volatile", "const"
AC_SYS_LARGEFILE (just unconditionally -D_LARGEFILE_SOURCE?)

configure once, compile many times

Posted Apr 30, 2025 14:03 UTC (Wed) by abatters (✭ supporter ✭, #6932) [Link]

> When you have 24 threads, just run 24 configures (for different build types, different packages), problem solved ;-)

Indeed; that is what Yocto does.

configure once, compile many times

Posted Apr 30, 2025 14:49 UTC (Wed) by marcH (subscriber, #57642) [Link]

> When you have 24 threads, just run 24 configures (for different build types, different packages), problem solved ;-)

This is useful but it's a different type of inefficiency because all these threads repeat mostly the same things.

Some smart caching would help in both situations.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds