On Fri, Apr 11, 2008 at 11:44 AM, Kevin Quick <[EMAIL PROTECTED]> wrote: > On 10 Apr 2008, at 12:01 AM, [EMAIL PROTECTED] wrote: > > > Attached is a patch that will upgrade Compile/MakeRecipe to support the > Cabal > > build/library system (http://hackage.haskell.org/cabal) used for Haskell > > (GHC). This performs the build using the standard Haskell methodology, > > registering the results to make it available for import in Haskell > programs. > > This also allows the easy reference to the Hackage library database > (http:// > > hackage.haskell.org/) for Haskell. > > > > No management of the local Cabal database is made beyond the initial > > registration; specifically DisableProgram, SymlinkProgram, and > RemoveProgram > > will require corresponding manual modifications of the database (e.g. via > ghc- > > pkg), but installation and upgrades of packages are handled quite nicely. > > > > The issue here is that the Cabal database (visible via "$ ghc-pkg list") > should be told when a new version is selected or a version is removed. It > supports hide/show (like Gobo's DisableProgram/EnableProgram) and unregister > (viz. RemoveProgram). However, to effectively perform these, all of the > various Gobo Scripts would need to look at the recipe type to detect a cabal > recipe and then perform the needed actions. That's not really possible with Disable/Remove, or package installs, since there's no way to know what the recipe type was originally. > If this package is going to move forward, then I would look into Scripts > updates, but I didn't want to spend the work if this patch wasn't > acceptable. Ok. I think this patch is fine, but I don't think that anything more would be plausible for the reason above. However, we don't usually like writing into other programs' directories (GHC's to update the database). I don't suppose this is really much different to ldconfig, but it won't happen on a package installation, so it would still have to be done manually in that case. I guess we're just relying on people knowing what command to use here.
I am ok with including that part as-is, but probably after the upcoming Compile release (unless it's further away than I think?). You also need to update RecipeLint to accept your new recipe type and the variables it defines, so it doesn't choke with errors when you write a recipe using it. After that we can apply this, unless somebody else has some objection to it (note for those somebody elses: it *does* use `SandboxInstall -a $var_that_points_into_/Programs/GHC/Current`, so keep that in mind). -Michael _______________________________________________ gobolinux-devel mailing list gobolinux-devel@lists.gobolinux.org http://lists.gobolinux.org/mailman/listinfo/gobolinux-devel