2014-07-24 13:22 GMT+02:00 Sven Panne :

How can I change the prefix? The README doesn't describe this AFAICT.

Hmmm, it looks like the install paths are hardwired in hptool/src/OS/Internal.hs. Do I see this correctly? If yes, that's a bit unfortunate, an additional parameter to platform.sh or an environment variable would be nice. Furthermore, the executables are scattered 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 Even if one copies this to /usr/local, extending the PATH would be tiresome. Is this intended or is a common bin directory below usr/local/haskell-platform/2014.2.0.0 missing? The whole layout below build/target is somehow un-Linux-esque (it's basically structured the Windows way): Normal packages put their binaries below /usr/bin, their libs below /usr/lib, their docs below /usr/share/doc etc. How are other packagers on this list handling this?

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! On Thu, Jul 24, 2014 at 4:22 AM, Sven Panne 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. 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. That strucutre is currently set up to build something which is unpacked over /, which is probably what most people *don't want, *but is agnostic to the variety of layouts possible. On Thu, Jul 24, 2014 at 4:48 AM, Sven Panne wrote:

Hmmm, it looks like the install paths are hardwired in hptool/src/OS/Internal.hs. Do I see this correctly? If yes, that's a bit unfortunate, an additional parameter to platform.sh or an environment variable would be nice.

Yes - it would need to be added to Main.hs, and then plumbed to the right point in the code. Sound great.... I can haz pull request plz? (you knew that was coming... :-) )

Furthermore, the executables are scattered 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 ...

Normal packages put their binaries below /usr/bin, their

libs below /usr/lib, their docs below /usr/share/doc etc. How are other packagers on this list handling this?

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/... My preferred approach is to put the whole installation under one prefix, say /usr/loca/ghc/ghc-7.8.3/, in there there are /bin, /lib, and /share. As you point out, this is a pain for PATH... so what I do is have an "activation" script that symlinks all the executables in that tree up and over into /usr/bin (or /usr/local/bin). Now clean up is a snap: Remove the ghc-<version> tree you want gone, and then remove all the symlinks in /usr/bin and/or /usr/local/bin that are now dangling into it. Does this make sense for simple "untar, run a script" kind of distributions? For people packaging for OS distributions, using a host OS package manager, I suspect they prefer the "overlay it all" approach, because the package managers take care of the chore of remembering which files go with which thing and handle uninstallation. I could easily imagine two or more styles under src/OS for hptool: PosixLocalTarball.hs, PosixPackaged.hs, Ubuntu.hs, FreeBSD.hs, etc... - Mark

On Fri, Jul 25, 2014 at 12:32 AM, Sven Panne wrote:

The structure on GitHub is a bit confusing

As with past releases, we generally work on a branch until release.

With 2013.2.0.0 one could

easily specify a --prefix in the configure step, and everything worked

as expected.

I didn't realize anyone used it. But it should be easy enough to add. What about packages being unregistered? It is intentional. The package registrations are all prepared, but the final registration should happen after the tree is moved into place. Conventionally this was part of "make install". For the build, there should be an "activation" script added to the tree that the user runs after copying the tree to the final system.

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?

Becuase the platform is built from the GHC bindist, and traditionally we've keep the GHC supplied portions "pristine".

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.

Or equivalent functionality. I don't think we'll be going back to autoconf & make.

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

We need more people involved in the platform! - Mark