[gobolinux-devel] Enhance Compile to support Haskell Cabal builds

[Kevin Quick]

On 11 Apr 2008, at 4:16 PM, Michael Homer wrote:
> On Fri, Apr 11, 2008 at 11:44 AM, Kevin Quick <quick at sparq.org> wrote:
>>  On 10 Apr 2008, at 12:01 AM, quick at sparq.org wrote:
>>>
>>  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.

OK.  I added a Log_Normal note at the end of the Compile for cabal  
recipe_type, just to give folks a heads-up.

The only other way I can think of would be to scan the output of 'ghc- 
pkg list' and 'ghc-pkg field $x library-dirs | grep "/Programs/ 
$appname/$version"', but that's really kludgy.  The ghc-pkg name  
doesn't usually match the Gobo Program name, so *all* packages would  
have to be checked (the $x in the ghc-pkg field command above).  And  
this still wouldn't handle InstallPackage.

This does seem like a general need for Gobo Compile/Scripts.  The  
filesystem-as-a-package-manager concept is pretty nice overall, but  
sometimes there's some deregistration needed (above, ld_config,  
rebuild desktop db, rebuild mime db, rebuild font cache, etc.)


>>  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 understand.  Properly, the GHC Recipe would be updated (actually,  
probably patches would be needed) to establish the ghc-pkg database  
in /Programs/GHC/Settings or somewhere similarly appropriate.   
Hmm.... this would preserve the validity of this database over GHC  
upgrades as well; sounds like a definite possibility.

The Compile script uses the output of ghc-pkg to find the database  
location, so if GHC's Recipe was updated in this manner, this Compile  
patch should still DTRT.

> I am ok with including that part as-is, but probably after the
> upcoming Compile release (unless it's further away than I think?).

Great!  Sooner is better: I've got over a dozen cabal recipes to  
submit once I can set their dependency on a released Compile version  
that supports cabal recipes---including darcs 2.0.0 and XMonad 0.7.

> 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.

Done.  I've attached a new patch (that also finishes the MakeRecipe  
operation that I seem to have left unfinished in the previous  
patch).  The attached patch supercedes previous patches, and includes  
RecipeLint updates as well.

BTW, I also modified RecipeLint to complain about unknown recipe_type  
values.  Because my cabal recipes didn't tend to use additional  
controls beyond simply specifying the recipe_type, so they were all  
already passing RecipeLint... which they shouldn't have.  :-)

As I was updating RecipeLint, I noticed that sandbox_options doesn't  
seem to be listed in the checked declarations.  Should this be added?

> 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).

To that point, existing recipes performing cabal-style installations  
(recipe_type=manifest) using pre_install() to perform ghc-pkg  
operations manually also modify the same location, albeit without a  
SandboxInstall to watch over them.  Not that this excuses this patch  
from being a bad Compile patch, but just noting that it's no worse  
than what's already happening.

The var pointing to that location is dynamically determined, so it's  
not hard-coded and should be adaptable to the current system.

-KQ

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Compile_add_cabal_3.patch
Type: application/octet-stream
Size: 4491 bytes
Desc: not available
Url : http://lists.gobolinux.org/pipermail/gobolinux-devel/attachments/20080412/69c10d85/attachment.obj