Skip to content
This repository has been archived by the owner on Aug 2, 2020. It is now read-only.

Allow caching of configure results. #607

Open
AndreasPK opened this issue May 21, 2018 · 6 comments
Open

Allow caching of configure results. #607

AndreasPK opened this issue May 21, 2018 · 6 comments

Comments

@AndreasPK
Copy link

AndreasPK commented May 21, 2018

Running configure takes a lot of time on windows.

Having a flag to use cached configure data for rebuilds would speed this up nicely.

I can run configure for GHC with -C myself. But adding the flag for the configure process of base is a different story.
Ideally libraries would also use the same configure cache as ghc, so it would be faster even on the first build:

Here are the times for base and ghc itself on my machine. (SSD, skylake i7)

name ./configure ./configure -C (rerun) difference
ghc 61 s 18s -43
base 1m 40s 31s -1m 9s
@snowleopard
Copy link
Owner

@AndreasPK Good idea! Now that we got rid of ghc-cabal we should have a more fine-grain control over how packages are configured.

Let me tag @angerman @alpmestan @izgzhen -- I think they are more knowledgeable in how this corner of Hadrian could be improved.

@alpmestan
Copy link
Collaborator

@AndreasPK and I discussed this a little more on IRC. autoconf's caching mechanism handles a lot of the work. Andreas pointed out that we probably just need to run the "toplevel" configure script with -C and then pass --configure-option=-C to all the cabal packages when we're configuring them. This is expected to make a noticeable difference on Windows, but not that much on Linux.

@angerman
Copy link
Collaborator

Configure on macOS feels quite a bit slower than on Linux as well. For crosscompilation the slowness is just comical.

@angerman
Copy link
Collaborator

This used to be discussed on #ghc a few years ago, and I’m not sure about the exact details anymore, but I believe there was some fear around stale state. Maybe @bgamari remembers...

@AndreasPK
Copy link
Author

I think it would be great to have the option. If it's a good default is indeed a different topic.

This used to be discussed on #ghc a few years ago, and I’m not sure about the exact details anymore, but I believe there was some fear around stale state. Maybe @bgamari remembers..

Personally I don't think this is a major issue if we delete the cache on make clean. There are already lot's of ways to break a working build tree with lingering build artefacts where make clean is required to fix it.

But I'm also perfectly happy if we make this available just as an optional setting.

@angerman
Copy link
Collaborator

I'm absolutely in favor of having this! I just wanted to add some history.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants