3 ms·
> One annoyance is that it often feels like "./configure ..." takes longer to run than the actual "make". Agreed. The configure script doesn’t take advantage o
by db48x 6y ago
> One annoyance is that it often feels like "./configure ..." takes longer to run than the actual "make".
Agreed. The configure script doesn’t take advantage of concurrency, but make can.
But the number one cause of slow configure is that people forget to run configure -C. The -C option makes it cache the outcome of all of the tests, so that it doesn’t have to do them all again. This is a huge time–saver!
- deleted 6y ago[deleted]
- xzzze 6y agoSince ./configure just probes the compiler it could be paralellized. Make has concurrency (-j4) why doesn't ./configure have the same feature
- zvr 6y agoBecause typically make produces a number of independent targets (for example, object files of different source files) while configure only produces a single output file containing all variable assignments.
- db48x 6y agoIt’s also a shell script. It’s a shell script written purely in POSIX–compatible sh, that is generated by the worst M4 script ever written. The information which will be printed to stdout, to the log files, to the cache files, to the status file, and so on all needs to be buffered until the end of any asynchronous task, then written atomically so that it can be understood and will work consistently. That’s synchronizing writes to six or seven different file descriptors, just so that everything comes out in a comprehensible order. I bet you're already thinking about how to implement it though. And it does quite a lot more than just probe the compiler. And finally, it doesn’t support concurrent execution because nobody who was tried to write it has returned. Usually it starts with confident estimates and preparations, followed by departure and sporadic reports. Gradually the reports dwindle in frequency and comprehensibility, until eventually nothing more is heard.
- pdimitar 6y agoSo it's impossible?