Opened 22 months ago

Closed 9 months ago

Last modified 9 months ago

#7017 closed task (fixed)

Rethink need for tarballs under "friendly" environment

Reported by: FUZxxl Owned by:
Priority: high Milestone: 7.8.1
Component: Build System Version: 7.4.2
Keywords: Cc: pho@…, mail@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Other Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

I just compiled GHC from git.

I am amazed that one needs to download extra 200 MiB of tarballs and 100 MiB of libraries to compile GHC. The tarballs directory essentially only includes a Perl and a MinGW binary. Is this really needed for anything if not building under environments like Windows where getting that might be difficult?

It would certainly be nice to rethink the building system as to shrink the number of additional MiB's one needs to download to make the compiler work.

Change History (7)

comment:1 Changed 22 months ago by simonmar

  • Difficulty set to Unknown

We do have a new 84MB mingw64 tarball, which means that the ghc-tarballs repo is now about 130MB. That's unfortunate. It might have been better to make a new repo for this, so that only Win64 builds have to get it. What are we going to do for the source distribution?

What is the "100MiB of libraries" referred to in the ticket?

comment:2 Changed 19 months ago by igloo

  • Milestone set to 7.8.1
  • Priority changed from normal to high

We should make a decision about this and close the ticket, so I'll mark it high so that we don't just let it languish.

The two options are:

  • Bundle everything in one, as we do now. Makes it convenient for users, but downloads are large and it uses more disk space.
  • Have 2 (or more) separate tarballs, and require the user unpacks the right ones for their platform. Possibly confusing for people trying to build GHC.

comment:3 Changed 19 months ago by simonmar

I vote for two source tarballs. Furthermore, I vote for putting the mingw64 tarball in a separate repo, that you only have to get on Windows (sync-all can manage to do this, I'm sure), and re-make the ghc-tarballs repo so that it doesn't include the mingw64 tarball in the history. We already have logic in sync-all to check for old repo versions, so that shouldn't cause any problems.

comment:4 Changed 15 months ago by PHO

  • Cc pho@… added

comment:5 Changed 10 months ago by nomeata

  • Cc mail@… added

I was just made aware of the tarballs with binary code in the “source” tarball. Theoretically, for Debian either the source of that code needs to be included as well, or the binaries removed. As we use none of the data in ghc-tarballs, we’d greatly appreciate a second tarball that contains just the GHC sources, and no third-party modules.

comment:6 Changed 9 months ago by igloo

  • Resolution set to fixed
  • Status changed from new to closed

The Windows tarballs are now in a separate repository, and end up in a separate tarball.

comment:7 Changed 9 months ago by nomeata

The Windows tarballs are now in a separate repository, and end up in a separate tarball.

Thanks, very much appreciated!

Note: See TracTickets for help on using tickets.