-
Notifications
You must be signed in to change notification settings - Fork 696
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
make hugs, nhc, lhc and Cabal agree on installed package info #49
Comments
(Imported comment by @dcoutts on 2006-01-09) We install the InstalledPackageInfo with each package (I didn't know that, but apparently we do). So in theory all we need to do is read those files back in and we have a package database. Of course it would be better if hugs came with the package registration files for all the core packages. |
(Imported comment by @dcoutts on 2008-01-17) So I'm happy with the idea that for hugs and nhc that we do not need a distinct concept of a package database. The package database can coincide with the location where packages are installed, and hugs/nhc just look in that dir for their packages. Cabal would also look there for the InstalledPackageInfo files. So the package db and the libdir are really the same thing. Hugs already looks in ~/lib/hugs/* for package directories. So for hugs there are two things to do:
|
(Imported comment by @dcoutts on 2008-08-15) This isn't tht hard but needs changes in Hugs and a bit in Cabal and then testing and a new hugs release. The scheme with installed package info files should work for hugs, nhc and lhc. On the Cabal side of things the same implementation can be used for each. |
Closing as there's been no activity in years. We're cleaning up the bug tracker to make it useful again and are thus closing bugs that haven't seen any activity in a long time. Please re-open (or file a new bug) if the problem reappears. |
(Imported from Trac #42, reported by @SyntaxPolice on 2006-01-09)
A pretty simple approach:
The package database is a list, mapping package names to directories.
Maybe the gentoo folks and others would be happier if it's a
directory where each file name is a package name and the content of
that file is a directory to find the source for this package.
If we go the "don't alter hugs" route, we'd need a wrapper around hugs
(maybe cabal) to read this file and add the -i flags to the hugs
command-line.
So this could be implemented outside of hugs, with just cabal and
hugs-pkg, then we could include a concept of a package database in the
cabal interface to make toast / gentoo happy. In fact, we
could do all that in Cabal without a hugs-pkg.
Of course, it would be nice if someone could say ":package foo" on the
Hugs command-line, but that's not completely necessary. We could punt
on that until we get more clear about the role of packages in the
language.
When implementing this, be sure to add
Problems with not having hugs-pkg
The text was updated successfully, but these errors were encountered: