[Haskell-cafe] Re: Hackage on Linux

[Mathew de Detrich]

I agree with this comment in regards to cabal building binaries for similar
reasons that John Macheam is. Cabal is fine for libraries (in fact I can
classify it as pretty damn good) but for binaries it is a different matter
for programs that don't use a simple build system/structure. Cabal is just
too inflexible, and then you have the issues with no uninstall (if the
binary also happens to create libraries) which just makes things more
painful

In all honesty, using a CMAKE like system for Haskell would have had a lot
more advantages then cabal for binaries.

The minute you have to install binaries on Windows using cabal that bring in
C (and other dependencies) and things are much more complicated then they
should be and are likely to break far too often then is considered sane

In my opinion this is one of the few things that is holding Haskell back in
regards to it being adopted by Windows users (among other things)

On Fri, Aug 27, 2010 at 9:13 AM, Andrew Coppin
<andrewcoppin at btinternet.com>wrote:

> Simon Marlow wrote:
>
>> If you look at the original Cabal design document[1], you'll see that one
>> of the goals of Cabal was to be the glue that lets you convert an arbitrary
>> Haskell library into a native package for a variety of systems - including
>> MSIs on Windows.  Indeed, I must admit when we were designing Cabal I
>> thought that native packages would be the most common way that people would
>> install Cabal packages, specifically because many systems already have a
>> good package manager, and trying to bypass the system package manager would
>> be a fundamental mistake.  It turned out that cabal-install would be a lot
>> more useful than I imagined, but the two systems are complementary: native
>> packages are for installing globally, and cabal-install is for installing
>> packages in your home directory.
>>
>
> Why would you ever want to install a package per-user? I mean, if you don't
> have permission to do a global install, then you also don't have permission
> to install GHC in the first place so...? Indeed, the *only* plausible reason
> I can think of is if you're trying to build something that has unusual
> package version constraints, and you want to build it without upsetting the
> entire system.
>
>
>  Even on systems without a package manager (i.e. Windows), it would make
>> more sense when installing a package globally to build an MSI first, so that
>> the system can track the installation and let you uninstall it later.
>>
>
> I did have a look at building a binary installer using Nullsoft NSIS.
> Unfortunately, I don't know of any tool in existence that can build MSI
> files that isn't absurdly expensive. (E.g., InstallShield is ~£4,000, which
> is extortionate for a program that just copies files around. Even BackupExec
> isn't *that* expensive, and that's mission-critical!)
>
> Of course, *I* was looking at NSIS specifically for installing Haskell-to-C
> bindings. These are virtually impossible to build on Windows, and I figured
> if I could build such a package once, I could then make a binary installer
> out of it and never again have to build it from source. (Until the next GHC
> version, anyway.) But I utterly failed to make the building part work, so I
> never got to the next bit.
>
> If you were to use binary installers for regular Haskell packages, the only
> real benefit would be that you can now UNinstall them again. It might be
> worth doing that, and it looks plausible that you could automate it...
>
>
>  [1] http://www.haskell.org/cabal/proposal/
>>
>
> Interesting. So Cabal was never intended to handle executables at all. (The
> entire proposal speaks only about *libraries*.) Suddenly several of Cabal's
> deficiencies make a lot more sense. It doesn't handle executables properly
> because it was never designed to. It doesn't uninstall because Cabal
> packages are supposed to be converted into real packages first, and real
> package managers provide uninstall capabilities. And so on.
>
> It's slightly disturbing how the proposal meantions "make" every three
> sentences. You realise that make only exists under Unix, right? There _are_
> other operating systems out there...
>
> I also can't for the life of me work out why something *designed for*
> automatic processing is designed without machine-readable syntax. Even in
> this early proposal, Cabal is already using that horrid ad hoc undocumented
> file format that only Cabal itself can actually parse and understand. Why
> not XML or JSON or *something* with a formal spec and a wide range of
> available tools? It makes no sense at all. And in case somebody is sitting
> there thinking "It IS documented. It's simple, isn't it?", did you know that
> file paths have to be escaped like Haskell string literals? No, I bet you
> didn't. Where is this fact documented? It isn't. Why was this decided? I'm
> guessing it's an implementation accident rather than a deliberate decision.
> Now if this were XML or JSON, everybody would already *know* the escaping
> rules. And we'd have tools that know about these rules and can handle
> processing such files. People seem to think that Cabal's existing format
> makes it easier for humans to read and write, but personally I'm always left
> wondering exactly which constructions are or aren't permitted. Can I put
> several values on a line here, or do they have to be seperate lines? Do all
> the field values have to be indented by the same amount? How does Cabal
> figure out which fields are subfields anyway?
>
> In summary, I would be *so* much happier if we had a real file format
> rather than this ugly home-grown thing. Unfortunately, this would break
> everything on Hackage, so it will never be fixed.
>
>
>  [2] http://www.haskell.org/pipermail/cabal-devel/2007-August/000740.html
>>
>
> Also interesting. I've never heard of WIX before...
>
>
> _______________________________________________
> 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/20100827/375a3996/attachment-0001.html