Hi, I've noticed that when you run ./configure on a ghc build lot's of repetition occurs. A lot of the time the same checks are being performed for each configure file in the ghc hierarchy. Could it be possible if some of these checks could be done once at a high level and then subsequent configures could refer to these checks to speed up configuration time? It's just configuring ghc on a mac G4 is a very time consuming process in it's own right! Thanks, Kind regards, Chris.
C.M.Brown wrote:
I've noticed that when you run ./configure on a ghc build lot's of repetition occurs. A lot of the time the same checks are being performed for each configure file in the ghc hierarchy. Could it be possible if some of these checks could be done once at a high level and then subsequent configures could refer to these checks to speed up configuration time? It's just configuring ghc on a mac G4 is a very time consuming process in it's own right!
Mainly this is due to modularity: many of the library packages can be built entirely separately from GHC, so their configure scripts are designed to be standalone. I know that configure takes a long time on Windows, but I'm surprised if it's a bottleneck for other platforms. How long does the build take? Have you taken steps to speed up the build as described in the Building Guide? Cheers, Simon
Hi Simon,
Mainly this is due to modularity: many of the library packages can be built entirely separately from GHC, so their configure scripts are designed to be standalone.
Yes, I guess it would be a fair bit of work to have it check that you are building the whole of GHC as opposed to separate modules. I just thought that it could check to see if it was a global build -- and share configure checks where appropriate; or, in separate module builds the configure runs as normally.
I know that configure takes a long time on Windows, but I'm surprised if it's a bottleneck for other platforms. How long does the build take? Have you taken steps to speed up the build as described in the Building Guide?
Configuring and building on my Mac can take several hours. Mind you, it's a slow machine (G4 1.33 with 1 gig of RAM). I can safely say it's very fast on my linux machine - the configure whips through, and even a full build only takes a little more than an hour or so. Thanks for pointing out tips to speed up the build. I must confess my ignorance of not checking that! Kind regards, Chris.
Mainly this is due to modularity: many of the library packages can be built entirely separately from GHC, so their configure scripts are designed to be standalone.
library packages are haskell packages, and much of the configuration data should be common (plus a few package-specific checks). would it be possible to have a "configuration package" with nothing but the common checks? then every package, and ghc itself, could depend on that package being there, and every package configure could modularly use the information from that package. such a package might also encode the information in haskell, for use in cabal? perhaps creating such common info should be a cabal feature, factoring common checks from the package configure files to cabal, which would need access to some shared configuration file to store and retrieve the info? that way, once you've got cabal built on a platform, there'd be no need to repeat the common suspects of tests in individual configure files? just thinking out loud,-) claus
On Tuesday 01 May 2007 13:02, Claus Reinke wrote:
[...] would it be possible to have a "configuration package" with nothing but the common checks? then every package, and ghc itself, could depend on that package being there, and every package configure could modularly use the information from that package. [...]
That would be the wrong approach, autoconf already has the relevant mechanisms: http://www.gnu.org/software/autoconf/manual/html_node/Caching-Results.html http://www.gnu.org/software/autoconf/manual/html_node/Cache-Files.html Basically, this boils down to using the AC_CACHE_BLAH macros in all time-consuming places (we do this, at least most of the time) and pass down the cache file location through the directory hierarchy (You won't achieve caching between siblings in the build hierarchy, but I am not sure if this is a real problem). This is what configure usually does, but I guess that some things have been broken by the recent changes in the build system, so that currently caching is not very effective. My personal opinion is: Compared to the whole build time, the configuration checks are ridiculously fast, and doing arcane things to speed this up is not worth the trouble. Cheers, S.
On Tuesday 01 May 2007 13:02, Claus Reinke wrote:
[...] would it be possible to have a "configuration package" with nothing but the common checks? then every package, and ghc itself, could depend on that package being there, and every package configure could modularly use the information from that package. [...]
That would be the wrong approach, autoconf already has the relevant mechanisms: .. My personal opinion is: Compared to the whole build time, the configuration checks are ridiculously fast, and doing arcane things to speed this up is not worth the trouble.
if i recall my intentions from that time correctly;-) it was less a question of speed, but of (a) avoiding duplication and (b) lifting the info from autoconf and co to haskell. better autoconf caching might address (a), but not (b). in other words, it might be nice if all haskell code, including cabal, ghc, libraries, .. could depend on a single platform-specific package, and if successful installation of that package on a platform would make the autoconf results available in the form of include-files and haskell modules. in other words, for generic platform specifics, only that single package would need autoconf, other library packages and haskell applications (the majority of portable haskell code?) might be able to drop the autoconf dependency completely, and the remainder could at least focus on the platform issues specific to their function (such as OpenGL, OpenAL, ..). in yet other words, how much more useful could System.Info become? but it was just a suggestion, claus
participants (4)
-
C.M.Brown -
Claus Reinke -
Simon Marlow -
Sven Panne