[Haskell-cafe] Listing native package requirements based on cabal information

[Rogan Creswick]

On Tue, Mar 18, 2014 at 11:48 AM, David Thomas <davidleothomas at gmail.com>wrote:

> One option that just occurred to me would be to allow passing a script to
> cabal that could be passed the extra-libraries (if any), and could install
> if it knew the relevant OS packages (or NIX packages), or abort with a
> cleaner error message.
>
>
You can do this sort of thing in a custom Setup.hs (using build-type:
custom).  Depending on the hook you use, you can get access to the cabal
file fields there directly.

--Rogan


> Actually, wrapping ghc might be sufficient (though not ideal).
>
>
>
> On Tue, Mar 18, 2014 at 11:29 AM, Michal Antkiewicz <
> mantkiew at gsd.uwaterloo.ca> wrote:
>
>> This is not an immediate solution but I can imagine listing NIX packages
>> as dependencies inside a cabal file, then NIX would create a sandbox with
>> these dependencies and cabal would build in that sandbox. The advantages
>> are that you're not messing around with the underlying operating system's
>> packages, NIX handles all dependencies transitively, and everything is
>> specified declaratively. Sounds like a nice GSoC project :-)  You could
>> also do cross GHC version's builds as GHC itself can be sandboxed. Quite
>> intriguing.
>>
>> Michal
>>
>>
>>
>> On Tue, Mar 18, 2014 at 2:16 PM, Michal Antkiewicz <
>> mantkiew at gsd.uwaterloo.ca> wrote:
>>
>>> Certainly NIX is an interesting approach. It already comes with a large
>>> base of dependencies, a format for specifying them. NIX can be installed in
>>> any Linux distro and serve as an environment for building packages. That
>>> might provide a cross-distribution solution to the native dependency
>>> problem.
>>>
>>> See, a nice post by Oliver Charles
>>>
>>>
>>> http://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos.html
>>>
>>> Michal
>>>
>>>
>>>
>>> On Tue, Mar 18, 2014 at 1:59 PM, David Thomas <davidleothomas at gmail.com>wrote:
>>>
>>>> Ok, well, if that's the case I'd like to see about remedying that.
>>>> Anyone have any thoughts as to how to best go about this?  I'm not clear on
>>>> exactly what info lives where, especially across systems.  Entirely manual
>>>> population would be a (barely) acceptable fallback.
>>>>
>>>>
>>>> On Tue, Mar 18, 2014 at 9:36 AM, Dan Burton <danburton.email at gmail.com>wrote:
>>>>
>>>>> I have wished for this on multiple occasions. I don't believe such a
>>>>> thing exists as of yet.
>>>>>
>>>>> -- Dan Burton
>>>>>
>>>>>
>>>>> On Tue, Mar 18, 2014 at 9:26 AM, David Thomas <
>>>>> davidleothomas at gmail.com> wrote:
>>>>>
>>>>>> Is there a way to extract this?  I'm looking to make it easier for
>>>>>> newcomers to my project to get things building across different linux
>>>>>> distros.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Haskell-Cafe mailing list
>>>>>> Haskell-Cafe at haskell.org
>>>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>>
>>>>
>>>
>>> <mantkiew at gsd.uwaterloo.ca>
>>>
>>
>>
>>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140318/11756cf0/attachment.html>