kazinator 17 days ago

> Perhaps you can get away with that for small, young, or self-contained projects

Only a small subset of which could just switch to the parallel configure being proposed.

1
LegionMammal978 16 days ago

Well, the hope would be that such a thing had already existed years ago. But failing that, it would be nice if a parallel configure could become solid enough for new C/C++ projects to use today.

kazinator 14 days ago

I've rolled a successful caching mechanism for configure artifacts, in my biggest project. You install it as a git hook: post-checkout. The cache is keyed on a SHA256 sum taken over the configuration inputs. (The ones in the repo, not the environment. The host environment is assumed to be static.) These inputs do not change for many commits at a time when the configure system isn't touched. During a bisect operation, the cache can be expected to quickly warm up, reducing the number of configuration operations needed, even on the host where repository was just cleanly cloned and the cache is empty.

It's not parallel config, but it's pretty cool. In some ways it's better because when there's a hit it's instant.

It's quite synergistic with ccache as well. You navigate to a commit. You are informed that cash config info was retrieved successfully, so you skip configure and run make. All the objects are retrieved from ccache.

LegionMammal978 14 days ago

Yes, I get it, your own projects are impeccably well-organized. But it's hardly helpful for the rest of us, working with projects that organically grow and mutate over time.