1. 12 Apr, 2007 1 commit
  2. 15 Mar, 2007 2 commits
    • sven.panne@aedion.de's avatar
      Use update-alternatives for handling generic tool names · 1ee08bbe
      sven.panne@aedion.de authored
      ATTENTION: Packagers should read the following stuff carefully!
      GHC, Hugs and nhc come with various tools like runhaskell or hsc2hs. On the
      one hand this is quite handy, avoiding lots of tiny native packages, but OTOH
      this leads to a few problems:
         * The tools are not always identical in functionality.
         * The tools fight for a global generic name like "/usr/bin/runhaskell".
      These problems are not new and not unique to Haskell implementations, so for
      *nix-based system there is a tool called update-alternatives which handles
      those cases. The idea is as follows:
         * Each program/man page/etc. installs itself with a very specific name
           like /usr/bin/hsc2hs-ghc or /usr/share/man/man1/lua5.1.1.gz, so nothing
         * The (un-)installation scripts call update-alternatives to notify the
           system about new alternatives for a generic tool/manpage/etc.
         * Alternatives can be grouped together ("link groups"), so e.g. switching
           from Sun's Java to Kaffe switches compiler, JRE, manpages etc. together.
           Alas, this doesn't work well with the Haskell implementations yet,
           because they come with different sets of tools (in addition to runFOO):
             GHC:  hsc2hs
             Hugs: hsc2hs, cpphs
             nhc:  cpphs
           Either these tools should be disentangled fromt the Haskell
           implementations or all implementations should offer the same set.
           Opinions and recommendations on this topic are highly welcome.
         * This mechanism can be used to easily switch between several versions of
           the same implementation, too, but we are not yet fully prepared for that.
      As a first step, GHC now installs hsc2hs as 'hsc2hs-ghc' and does *not*
      install runhaskell directly anymore, only runghc. hsc2hs and runhaskell are
      created via update-alternatives now. What is currently missing is a mechanism
      for platforms like Windows and probably Mac OS X.
    • sven.panne@aedion.de's avatar
      Added support for parallel builds · cbb81129
      sven.panne@aedion.de authored
      With this patch, one can define the degree of build parallelism via a 'jobs'
      rpm variable. A comfortable way to use this is having a ~/.rpmmacros file with
      a line like:
         %jobs 2
      Alternatively, one could use a '--define "jobs 2"' command line flag for
      rpmbuild. On a Core 2 Duo using 2 jobs brings down the time for a full build
      including extralibs from 36m to 27m. If 'jobs' is not defined, a normal
      sequential build is done, following the usual conventions on e.g. openSUSE.
  3. 11 Jan, 2007 1 commit
  4. 10 Jan, 2007 1 commit
  5. 02 Jan, 2007 6 commits
  6. 12 Oct, 2006 1 commit
  7. 19 Sep, 2006 1 commit
  8. 04 Aug, 2006 1 commit
  9. 19 Apr, 2006 2 commits
  10. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
  11. 13 Nov, 2005 1 commit
    • panne's avatar
      [project @ 2005-11-13 19:07:17 by panne] · b36b3d13
      panne authored
      Move the building guide to GHC where it belongs. This is more consistent and
      currently even necessary, otherwise *every* fptools project would need the ghc
  12. 14 May, 2005 1 commit
  13. 10 Mar, 2005 1 commit
  14. 21 Jan, 2005 1 commit
    • panne's avatar
      [project @ 2005-01-21 18:06:26 by panne] · d9d77353
      panne authored
      * Require happy >= 1.15 for build
      * Build some needed PostScript docs
      * Merge the ghc-doc- sub-package into the ghc sub-package, it's quite
        unusual to find the docs for a package blah under
  15. 04 Dec, 2004 1 commit
  16. 23 Oct, 2004 1 commit
  17. 30 Sep, 2004 1 commit
  18. 19 Sep, 2004 1 commit
  19. 05 Sep, 2004 1 commit
    • panne's avatar
      [project @ 2004-09-05 19:12:20 by panne] · be0242d0
      panne authored
      * HTML documentation for "foo.xml" goes into directory "foo" again,
        not "foo-html". This is nicer and consistent with the behaviour for
        building the docs from SGML.
      * Disabled building PostScript documentation in the spec files for
        now, there are some strange issues with the FO->PS conversion for
        some files which have to be clarified first.
  20. 03 Sep, 2004 1 commit
  21. 01 Sep, 2004 1 commit
  22. 26 Aug, 2004 2 commits
    • panne's avatar
      [project @ 2004-08-26 21:03:18 by panne] · c1fa0428
      panne authored
      Updated BuildRequires tags. Alas, there seems to be no real standard here, so
      your mileage may vary... At least the current specs should work on SuSE Linux.
    • panne's avatar
      [project @ 2004-08-26 20:08:39 by panne] · a1939730
      panne authored
      SGML is dead, long live DocBook XML!
      Note: The BuildRequires tags in the spec files are still incomplete
      and the documentation about the DocBook tools needs to be updated,
      too. Stay tuned...
  23. 06 Jun, 2004 2 commits
  24. 05 Jun, 2004 2 commits
  25. 05 May, 2004 1 commit
  26. 19 Aug, 2003 1 commit
  27. 20 Sep, 2002 1 commit
    • lewie's avatar
      [project @ 2002-09-20 23:48:53 by lewie] · 5f4d3eb8
      lewie authored
      Make sure that permissions on installed files are right by adding
      `%defattr(-,root,root)' to the `%files' entries.
      Not a critical patch - Manuel built the rpms as root anyway, but this
      makes it so that you are not dependent on building the rpm as root.
  28. 16 Sep, 2002 2 commits
  29. 15 Sep, 2002 1 commit
    • lewie's avatar
      [project @ 2002-09-15 19:38:28 by lewie] · 1fbeffc0
      lewie authored
      Ergh!  Don't mix `%doc <relativepathname>' with `%doc <absolutepathname>'
      where <absolutepathname> is the standard doc directory (i.e. the same place
      where the <relativepathname> files will be copied).
      The <relativepathname> version has the hidden side effect of removing
      the contents of the doc directory first (and thus your carefully installed
      files).  The whole distinction which makes a special case for relative
      paths is a crock in the first place ;-)