Re: [Haskell-cafe] ghc ./configure stalls on docbook DTD
On 13/05/2009 19:53, Donnie Jones wrote: Hello Dan, Best place to ask is glasgow-haskell-users@haskell.org since that is the GHC users list. I have CC'd your email to the GHC user list. Cheers. -- Donnie Jones On Wed, May 13, 2009 at 1:35 PM, Dan wrote: Hi, Not sure if this is the right place to ask. GHC 6.10.3 source dist: ./configure takes about 10 minutes to look for DocBook DTD and another 10 to look for DocBook XSL directory. I was writing this e-mail thinking it had completely crashed. Any reason why it's so ridiculously slow? A look at 'top' says the CPU is mostly idle during this time, but xmllint is running. I have the following complaint from Roman in my inbox, which I think is about the same thing: > one big nuisance when building ghc is that configure tries to connect > to the internet. The culprit is the FP_GEN_DOCBOOK_XML macro in > aclocal.m4 which is used when checking for DocBook DTD. It generates > an XML file which references http://www.oasis-open.org/docbook/xml/4.2 > /docbookx.dtd and then runs xmllint which, naturally, wants to load > the dtd. Depending on the quality of my internet connection and on > the availability of oasis-open.org this check sometimes (infrequently > but very annoyingly) takes up to a 2 or 3 minutes for me. Given that > the DTD in question can be freely copied, why not redistribute it > with ghc? > Another www reference is in FP_GEN_FO (to > http://www.w3.org/1999/XSL/Format) but that never seems to bite me. I know almost but not quite exactly nothing about how to find DTDs. But I do recall that Duncan mentioned to me recently that there's a much better way to do this - Duncan? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] ghc ./configure stalls on docbook DTD
Hello Dan, Best place to ask is glasgow-haskell-users@haskell.org since that is the GHC users list. I have CC'd your email to the GHC user list. Cheers. -- Donnie Jones On Wed, May 13, 2009 at 1:35 PM, Dan wrote: > Hi, > > Not sure if this is the right place to ask. > GHC 6.10.3 source dist: ./configure takes about 10 minutes to look for > DocBook DTD and another 10 to look for DocBook XSL directory. I was writing > this e-mail thinking it had completely crashed. Any reason why it's so > ridiculously slow? A look at 'top' says the CPU is mostly idle during this > time, but xmllint is running. > > Mac OS X > > uname -a: Darwin 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST > 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386 > > CookBook:ghc-6.10.3 dan$ ./configure > checking build system type... i386-apple-darwin9.6.0 > checking host system type... i386-apple-darwin9.6.0 > checking target system type... i386-apple-darwin9.6.0 > Canonicalised to: i386-apple-darwin > [blah blah blah] > checking for xmllint... /usr/bin/xmllint > checking for DocBook DTD... > (blocks for ages) > > > ___ > Haskell-Cafe mailing list > haskell-c...@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc configure
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc configure
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc configure
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc configure
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc configure
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc configure
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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
