> My use case in Buildroot is very different: we build potentially > several dozens of different software components, each time with a > different toolchain/environment. So we're almost never rebuilding with > the exact same configuration, and therefore using a cache doesn't > really work for our use case. It sounds like there's already an appreciable amount of embarassingly parallel work in the environment as none of those builds should depend on any other. Non-parallel autoconf would hurt the latency of a single build but shouldn't cause much change in the throughput of builds one can achieve. My apologies if my experience doesn't line up with others-- my projects take 1-3 minutes to configure, somewhere between 10 minutes and an hour to build, and something like a month of straight computation on hundreds of nodes before I get an answer. Configure times just aren't my bottleneck. I'm not saying parallel configure wouldn't be nice, but that I keep seeing other ways to take advantage of caching and parallelism that don't require making a long-standing serial codebase parallel. - Rhys _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
