At long last: 2014.2.0.0 Release Candidate 1

[Sven Panne]

2014-07-24 16:24 GMT+02:00 Mark Lentczner <mark.lentczner at gmail.com>:
> On Thu, Jul 24, 2014 at 1:25 AM, Sven Panne <svenpanne at gmail.com> wrote:
>> The source tarball is missing a few files for hptool:
> I'll try to catch them the next round... or pull requests on github welcome!

The structure on GitHub is a bit confusing: It took me some time to
figure out that "master" is probably irrelevant by now, and
"new-build" contains the stuff for the upcoming HP. Is that correct?
If yes, one should probably merge back things to master and base the
HP releases directly on that. As it is, for new people things are
quite puzzling...

> On Thu, Jul 24, 2014 at 4:22 AM, Sven Panne <svenpanne at gmail.com> wrote:
>> ...But I'm a bit clueless how to proceed from that point: What I actually want is a
>> complete installation of the HP under a given prefix.
> Your build is using the genericOS set up in src/OS/Internal.hs. In the past,
> linux/unix distribution packagers have worked from the src tarball, and when
> I queired in the past, none said they used the build scripts HP had, but
> used their own. And in turn, no one put in any effort over the last six
> months to add a build decription using the new build system other than OS X
> and Windows.

Ah, OK, that was unclear to me, and it is a rather serious regression
compared to the previous platform release: With 2013.2.0.0 one could
easily specify a --prefix in the configure step, and everything worked
as expected. I really think that this use case should be resurrected
before the new HP is released: There are various reasons why pre-built
Linux packages are not an option for many people (having to wait until
a package is ready/fixed/etc. for one's distro, no root access, etc.),
so the --prefix option was and still is important here.

What about packages being unregistered? This seems to be a bug in
hptool, and it effectively makes the stuff below build/target
unusable.

> SO - what you, and we, need is a src/OS/GenericLinux.hs file so that it does
> you/we think is the generic layout for where things should live. For your
> own, peronsal install, you could start by just hacking on the genericOS
> structure in src/OS/Internal.hs. [...]

Guess what I did... ;-)


>> [...] Furthermore, the executables arescattered around:
>>
>> build/target/usr/local/haskell-platform/2014.2.0.0/lib/alex-3.1.3/bin/alex
>> build/target/usr/local/haskell-platform/2014.2.0.0/lib/cabal-install-1.18.0.5/bin/cabal
>> build/target/usr/local/haskell-platform/2014.2.0.0/lib/happy-1.19.4/bin/happy
>> build/target/usr/local/haskell-platform/2014.2.0.0/lib/hscolour-1.20.3/bin/HsColour
>
> My rationale is that if you install things under /usr/bin, /usr/lib,
> /usr/share/doc - then it becomes essentially impossible to remove easily:
> There are just far too many files in those trees intermingled with files
> from other things. Same is true if you do /usr/local/...

If you have either --prefix or use the tree below build/target to
assemble a package for your distro, that's a non-issue. As mentioned
above, we need --prefix anyway, so we should have a single
{bin,lib,share,...} structure directly below it. Even keeping the
distinction between the GHC parts and the rest of the platform is not
useful from a user perspective and to large parts totally artificial:
Why e.g. is haddock below GHC part, but alex below the HP part? This
is by pure technical accident, and it's unimportant when one installs
the HP as a whole.

> [...] Does this make sense for simple "untar, run a script" kind of distributions?

Partly, yes. It doesn't matter in detail how things happen, but we
need the ability of the simple and easy "./configure --prefix=foo &&
make && make install" from the 2013.2.0.0 HP back in the new HP source
release.

I hope that I don't sound too negative, you're doing great (and
unpleasant) work, I just want to make sure that we don't regress on
Linux platforms...