On Wed, 2008-03-05 at 08:41 +0000, Neil Mitchell wrote:

Hi

...

Both errors are a consequence of the fact that we do not know what packages are installed for hugs. It is printing all the packages that it thinks are missing, that is... none.

For cabal-install, I can accept this. But from what you are saying cabal seems to have recently become broken so that it just won't work with Hugs at all? That is a real shame.

I said:

So that second error simply needs to be fixed because the Cabal lib has previously worked with implementations that do not track installed packages. The sensible fix is probably just to skip the check entirely for hugs and other implementations where we do not know the installed packages.

And I've pushed the fix: Wed Mar 5 02:36:26 GMT 2008 Duncan Coutts * Fix configure for hugs where we don't know what packages are installed For Hugs, nhc98 and other compilers we do not know what packages are already installed, so we just make some up, pretend that they do exist and just hope for the best. We make them up based on what other package the package we're currently building happens to depend on. See inventBogusPackageId. Let's hope they really are installed... :-) One could see this as all rather redundant - carefully making up bogus information to satisfy a careful check. I prefer to see it as making explicit something that was previously implicit. The proper solution is to discover what packages are currently installed.

...

For a future hugs release it would be enormously helpful if it would include the InstalledPackageInfo files for all the bundled packages and if there was a way of discovering what directory to look in to find these packages. Then we could build a proper index of the installed packages as we do for ghc. Also we need a hugs --version flag so Cabal can actually figure out the hugs version so it knows whether it supports an installed package database. Currently hugs is almost unversioned (check System.Info.compilerVersion).

File suffient bugs (http://hackage.haskell.org/trac/hugs) and hopefully they will get fixed.

Ok. Duncan

Hi

And I've pushed the fix:

Wed Mar 5 02:36:26 GMT 2008 Duncan Coutts * Fix configure for hugs where we don't know what packages are installed For Hugs, nhc98 and other compilers we do not know what packages are

Which works perfectly. Any chance that (if its not too much effort) cabal install on Hugs could just assume that all the necessary packages are already installed? It would at least give me the ability to do "cabal install --hugs" in a darcs repo, instead of three runhaskell Setup invocations. Thanks Neil

Hi

...

Any chance that (if its not too much effort) cabal install on Hugs could just assume that all the necessary packages are already installed? It would at least give me the ability to do "cabal install --hugs" in a darcs repo, instead of three runhaskell Setup invocations.

Done. Give it a go...

No luck still: E:\Neil\yhc\src\libraries\core>cabal install --hugs cabal: user error (Pattern match failure in do expression at Hackage/Install.hs: 99:6-19) Thanks Neil

Hi

It looks like you have not recompiled, that line used to be:

Just installed <- getInstalledPackages verbosity comp packageDB conf

I recompiled using cabal clean && cabal install, but that didn't seem to pick up the change... In the end it took a runhaskell Setup configure/build/install to get it working. With that patch, I have now successfully installed things to Hugs using cabal install. It should be said that cabal install is absolutely wonderful - well done to everyone who has worked on it! Thanks Neil

On Fri, 2008-03-07 at 12:21 +0000, Malcolm Wallace wrote:

...

Wed Mar 5 02:36:26 GMT 2008 Duncan Coutts * Fix configure for hugs where we don't know what packages are installed For Hugs, nhc98 and other compilers we do not know what packages are already installed, so we just make some up,

Hmm, although you may not know, there is a way to find out. :-) On nhc98 at least, a simple directory listing of

A simple directory listing is absolutely fine!

include/packages/*.cabal

That tells us what package names and versions are installed but it doesn't help with finding out what the installed packages depend on or what cpp flags they used or anything else. For that we need the InstalledPackageInfo rather than the unconfigured .cabal files.

will tell you what is installed. I agree that this is not the friendliest interface in the world, so I have now made it easier, by adding the 'nhc98-pkg list' command (in darcs). For instance:

$ nhc98-pkg list array-0.1 base-3.0 bytestring-0.9 Cabal-1.3.6 containers-0.1 directory-1.0 filepath-1.1 fps-0.8 haskell-src-1.0.1.1 haskell98-1.0.1 HaXml-1.19.2 html-1.0.1.1 HUnit-1.2.0.0 old-locale-1.0 old-time-1.0 packedstring-0.1 parsec-2.1.0.0 polyparse-1.1 pretty-1.0 process-1.0 QuickCheck-1.1.0.0 random-1.0 xhtml-3000.0.2.1

So what we now use with ghc is to call 'ghc-pkg describe *' and it gives us the concatenation of the InstalledPackageInfo for every installed package. It's not at all a problem to go look in a dir, so long as it's always clear what dir to look in (eg nhc98 --print-libdir or equivalent), the most important thing for top-notch cabal support is knowing all the info about all the installed packages. It'll allows us to do pre-processing correctly, where installed packages provide header files or need certain cpp flags or use C libs. It'll allow cabal-install to generating correct install plans that respect the dependencies of existing installed packages. Duncan

On Fri, 2008-03-07 at 13:48 +0000, Malcolm Wallace wrote:

Duncan Coutts wrote:

...

That tells us what package names and versions are installed but it doesn't help with finding out what the installed packages depend on or what cpp flags they used or anything else. For that we need the InstalledPackageInfo rather than the unconfigured .cabal files.

With respect, the nhc98 compiler neither has nor uses an InstalledPackageInfo for any package. If Cabal wants that information, Cabal should (a) generate it, and (b) store it. I don't see the point of duplicating all that machinery in nhc98, when we don't need it. Cabal is the package manager, after all.

Yes, absolutely. For Hugs Cabal already generates an InstalledPackageInfo file and installs it with each package. We just need to get it to do the same for nhc98 which will be trivial. The one thing we'd need from nhc98 is for those generated files to be included for the core packages that come with a standard nhc98 install. Cabal can then take care of installing them for all packages the user installs later. So I guess we'd need to adapt the nhc98 build procedure a bit to use Cabal to generate the info files so they can be included into the install. Does that sounds reasonable? Duncan