Re: At long last: 2014.2.0.0 Release Candidate 1

2014-07-24 16:24 GMT+02:00 Mark Lentczner :

On Thu, Jul 24, 2014 at 1:25 AM, Sven Panne 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...

...

...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,

On Thu, Jul 24, 2014 at 4:22 AM, Sven Panne wrote: 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...