This repository has been archived by the owner. It is now read-only.

better GHC formula with support for 7.6.2 and bindist installs #18779

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
6 participants
Contributor

camillol commented Mar 27, 2013

There have been other pull requests for GHC, but I think this is the one that takes care of all concerns.

  • GHC is out of date: by default this installs the GHC compatible with haskell-platform, but you can pass --current to install the current stable version (these are going to be different most of the time due to the different release schedules).
  • Compiling from source takes forever, and bottles only exist for a given prefix and take forever to make: the GHC bindist can actually be installed into any prefix, so we take advantage of that and we don't need to make bottles again.
  • But someone may want to build from source: that's supported too (--source).
  • But 7.4.2 has a bug and needs a patch: that's why that version builds from source by default (and of course it uses the bottle that is currently available if installing to /usr/local).

Bottom line, this allows people to install 7.6.2 now and makes maintenance easier in the future.

I have tested installing 7.6.2 from binary to a custom prefix, installing 7.4.2 from source to a custom prefix, and installing 7.4.2 from bottle to /usr/local.

Contributor

camillol commented Mar 27, 2013

@samueljohn wanted to be pinged.

Contributor

samueljohn commented Mar 27, 2013

Thanks. I am mostly afk (iPhone only) over the Easter days.

Owner

MikeMcQuaid commented Mar 27, 2013

the GHC bindist can actually be installed into any prefix

Then the new bottles will work in any prefix too. I want us to keep building from source and not use upstream binaries. We're going to start bottling a lot more so any issues with bottles need to be fixed rather than just worked around.

Contributor

camillol commented Mar 28, 2013

No, the bindist is not just a bunch of files that you dump somewhere. AFAICT it contains the compiled object files, but without the final linking step, which is done after you configure it for the final installation prefix. But if you bottle up the final installation, it won't be relocatable.

Also, "I want" is not much of a reason. You're still welcome to make bottles if you want, but there's no reason not to use the upstream binaries when the bottles can't be used or when they haven't been made yet.

Owner

MikeMcQuaid commented Mar 28, 2013

No, the bindist is not just a bunch of files that you dump somewhere. AFAICT it contains the compiled object files, but without the final linking step, which is done after you configure it for the final installation prefix. But if you bottle up the final installation, it won't be relocatable.

If that's the case, fair enough. I'm still not convinced the bottles will not necessarily be relocatable unless there's lots of Qt-style embedding of the prefix as strings inside binaries.

You're still welcome to make bottles if you want, but there's no reason not to use the upstream binaries when the bottles can't be used or when they haven't been made yet.

Well, the same reason we rather not use upstream binaries: we would rather build from source and manage binaries ourselves. We're going to be doing a lot more building of binaries in the next year so I don't want to sidestep issues but instead actually seek to fix them.

Contributor

camillol commented Mar 28, 2013

It's not that there are issues with the bottles, here - and if there were, I'd want them fixed, too. We just don't have a generic mechanism for making all bottles relocatable, since a given formula can depend on the prefix in arbitrary ways - and that's ok. But in this specific case, we can take advantage of GHC's peculiar approach to binary distributions to provide support for arbitrary prefixes.

Also, building GHC from source still requires the GHC binaries, and it takes a really, really, really long time. So we'd be downloading the binaries, using them (which means they have to work!) to build exactly the same thing at a huge expense of time and energy, and then throwing them away. For this formula, I think we should only build from source when we need to apply a patch (as with 7.4.2), or maybe when the user wants to work on GHC itself. But I built GHC from source today, and I never want to do it again unless it's absolutely necessary. It's that slow.

Owner

MikeMcQuaid commented Mar 28, 2013

Considering I've built all the bottles on my own virtual machines: I'm aware of how slow it is. If we want to apply a patch we need to then change the build process again. That's why we currently bottle.

There have, in the last month, been various code changes to make bottles sometimes generically relocatable. If you don't want to build it again that's ok but I want to do so before we use the binaries instead.

Contributor

camillol commented Mar 29, 2013

If we want to apply a patch we need to then change the build process again.

That's FUD. This formula supports both installing from the binaries and building from source. 7.4.2 builds from source by default (because it needs a patch), while 7.6.2 builds from the binaries (because it doesn't). It takes less than one line of code to switch, so it's a non-issue.

Actually, it's an argument in favor of this patch: the existing GHC formula only supported building from source, and I had to spend a lot of time making this patch so that I could install 7.6.2 from the binaries. But if we apply this patch, that won't be a problem any more.

Also, this is not a threat to your work on bottles. You don't have to try to kill it. It's one formula, using a specific approach that only applies to GHC (but makes a lot of sense for GHC), so it doesn't impact the generic mechanisms.

Owner

MikeMcQuaid commented Mar 29, 2013

Whatever. I'll let other maintainers chip in. I'm not merging this until I've tested the bottle support and I'd suggest to other maintainers we don't do so either.

(For future reference when you start tossing around phrases like 'FUD' it kills my motivation to actually have a discussion)

Contributor

camillol commented Mar 29, 2013

We can't have a worthwhile discussion if you won't even look at the patch first.

Owner

MikeMcQuaid commented Mar 29, 2013

I did. Which "less than one line" do you switch to make bottles work with this approach?

Contributor

camillol commented Mar 29, 2013

Bottles already work. If you use this formula and homebrew is in /usr/local, by default you'll get the 7.4.2 bottle. If you pass --current, you'll get 7.6.2, which is installed from the upstream binaries. If you decide to make bottles for it you can simply add them in the appropriate place in the formula (admittedly, a bottle block takes more than one line, but that's not my fault :) ).

The "less than one line" was about switching to building from source so we can apply patches: you just have to change the condition in build_source?. For example, if it turned out that we always need to build from source on Leopard to apply a patch specific to that OS, you'd add or MacOS.version == :leopard (which is less than a whole line).

Owner

MikeMcQuaid commented Mar 30, 2013

The bottle isn't relocatable, I checked. It looks like it could get there with a bit of work as the bulk of GHC has been relocated. Might investigate fixing up the various text files and playing with relocating haddock and Cabal properly.

I think there's some good ideas here but it makes the formula way overcomplicated. I'd be for just sitting on 7.4 until haskell-platform is updated and then updating this to 7.6. I'm open to other maintainers views on this.

Contributor

samueljohn commented Mar 31, 2013

As a side note:
brew install <RAWURL-OF-THIS-PR> -v errors out for me
Perhaps Xcode-only setup. Perhaps non-standard homebrew location.

Contributor

samueljohn commented Mar 31, 2013

update: I have the same issue with the current ghc formula.

Contributor

Sharpie commented Apr 2, 2013

We switched to bootstrapping from source for very good reasons discussed at length in #13519. Specifically, see my comment where I note that the bindist appears to work well for users running the same version of OS X as the developer who rolled it up, but poorly for users of newer or older OS X releases.

Bootstrapping our own bottles is a pain, but ensures that GHC was specifically built for the OS X release that it will be running on.

So, before we ponder switching back to the bindist, we have to answer the question: has the quality of the builds improved enough since 7.4.2 to justify the risk?

Contributor

camillol commented Apr 4, 2013

@samueljohn I've tested using a custom homebrew location, so that shouldn't be the problem.

@Sharpie I've read #13519. The initial issue seemed to be using mismatched versions of GHC and H-P. Then @dysinger mentioned issues with the bindist on Mountain Lion, but he never provided specifics, nor a reproducible testcase. The one specific issue that was mentioned is http://hackage.haskell.org/trac/ghc/ticket/7040 , which is patched in this formula. Of course, having to apply a patch was reason enough to have source builds at that point, and the other supposed issues were never mentioned again.

OTOH, everyone I've talked to on #haskell recommends using the binaries for GHC and/or H-P, and they recommend against using Homebrew. But of course, if you use them directly you lose the convenience of upgrading and uninstalling using Homebrew.

BTW, I think we should follow a policy of explaining non-obvious decisions in comments in the formulas. In this case, though, it turns out that it could not be done simply because no specifics were ever provided. It is entirely possible that the problem was only with 7.4.1, or that it was some other issue, and the version mismatch was just a hunch. Even if the problem was also in 7.4.2, this formula still builds that version from source because it needs the patch.

I think it's wiser to support both source-builds and binary installs, as this patch does. I don't think we should assume that the official binaries are always going to be broken, especially when we have no test case to show that it might be so. And even if it did, it would make sense to contribute the findings upstream and help them fix their builds, so again it wouldn't be a reason to remove the binary path entirely.

Contributor

eagleflo commented Apr 7, 2013

I'm in agreement with @camillol here. If there's a problem with the official binaries, let's help get them fixed upstream. Furthermore, @MikeMcQuaid's suggestion of sitting on 7.4 until the next version of Haskell Platform is released is not a good way to go for a few reasons:

  • Many Haskell users prefer to use the latest version of GHC and install the packages provided by Haskell Platform from Cabal manually.
  • Haskell Platform has historically had a very erratic release schedule. It could be late by six months again.

I'm of the opinion that the GHC formula should provide the latest official stable release of GHC. Ruby and Python formulas for example seem to be updated almost immediately when a new release is made, while GHC is constantly stuck in an old version due to haskell-platform's dependency on it (7.6 came out in last September).

Could GHC 7.4 be moved to homebrew-versions and have Haskell Platform depend on that until it's updated? Does Homebrew support depending on versioned formulae?

If that's not an option, I'd like to see the latest version provided with a switch at least. We used to use --devel before but --current is probably the better choice, even if slightly apologetic.

Contributor

eagleflo commented Apr 29, 2013

@mistydemeo suggested that a Ghc74 subformula could be created within the Haskell Platform formula and thus separate it from the GHC altogether. This seems like a mighty good idea to me. Also, GHC 7.6.3 has already been released in the meanwhile.

I'll have a go at updating all related formula (ghc, haskell-platform, cabal-install) later tonight.

Contributor

camillol commented May 23, 2013

Updated to 7.6.3. Is there any reason left not to merge this?

cartazio commented Aug 8, 2013

I"ll try and read the conversation on this ticket in the next day or so and hopefully make some helpful remarks subsquently

Owner

MikeMcQuaid commented Aug 8, 2013

@cartazio Please don't; this is closed. If you want to discuss these things please take it to the mailing list.
@camillol You appear to be in "piss off the core contributors" mode again.

Contributor

camillol commented Aug 8, 2013

@MikeMcQuaid what are you saying? You yourself wrote, in this very thread: "I think there's some good ideas here but it makes the formula way overcomplicated. I'd be for just sitting on 7.4 until haskell-platform is updated and then updating this to 7.6. I'm open to other maintainers views on this." This is a great opportunity to get input from the Haskell Mac community. I'm not trying to reopen this ticket, obviously, but we can have a useful discussion on what to do with the GHC formula in the future.

We can choose a different forum if you prefer, but that's no reason for you to get "pissed off".

Owner

MikeMcQuaid commented Aug 8, 2013

This is a closed pull request. We're using our bottles rather than the bindist. The conversation was had.

Owner

MikeMcQuaid commented Aug 8, 2013

I'll accept a pull request that builds the bindist and then we can use a bottle that has cellar :any.

handyman5 pushed a commit to handyman5/homebrew that referenced this pull request Oct 7, 2013

ghc 7.6.3
Closes #14820.
Closes #18362.
Closes #18779.

@eagleflo eagleflo referenced this pull request May 12, 2014

Closed

GHC 7.8.2 #28350

@xu-cheng xu-cheng locked and limited conversation to collaborators Feb 16, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.