GithubHelp home page GithubHelp logo

gentoo-haskell / hackport Goto Github PK

View Code? Open in Web Editor NEW
53.0 53.0 22.0 2.7 MB

A command line tool to generate Gentoo ebuilds from Hackage packages.

License: GNU General Public License v3.0

Haskell 99.79% Shell 0.21%

hackport's People

Contributors

cnd avatar dcoutts avatar dmalikov avatar ewilbur avatar ezzieyguywuf avatar hasufell avatar hololeap avatar jamiahx avatar khumba avatar kolmodin avatar kosmikus avatar l29ah avatar markwright avatar miezhiko avatar pbarill avatar qnikst avatar renegat96 avatar solpeth avatar trofi avatar vikraman avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

hackport's Issues

Add flag to edit cabal file before merge

Since it often makes sense to edit the .cabal file before generating the .ebuild, why not add a --edit-cabal flag so that you can bring it up in a text editor with hackport merge?

In a similar vein, a --preview flag could show you the generated .ebuild without saving it.

It would also be nice to be able to configure it so that the --edit-cabal flag is on by default. This might mean adding a --no-edit-cabal flag as well.

hackport cannot correctly port ghc-exactprint

For library, ghc-paths is required.
For some executables, ghc-paths is required only when a certain flag is required.

hackport fails to make ghc-exactprint depend on ghc-paths unconditionally.

[Feature] Teach hackport to assist in bumping major GHC versions

Teach hackport to determine the maximum GHC version required by packages in ::haskell

Preamble
Currently, to bump major GHC versions, we have to do something like the following:

  1. Bump and/or mark bundled libraries in ::haskell
  2. Generate GHC binaries for bootstrapping
  3. Build 75% of ::haskell, including 'critical' packages detailed in the docs

Step 3 is consistently the biggest hurdle, in that it takes a lot of time. But, of course, it is absolutely necessary to determine if ::haskell is going to be otherwise broken by a major compiler upgrade. I did step 3 for 8.0 -> 8.4, and again from 8.4 to 8.6. But I would much rather if I had a build server to do this for me, as my laptop isn't going to be able to put up with it forever.

While I sort out sourcing a server to get set up on (I have considered AWS, but I haven't gotten very far with that idea), I thought that hackport may be able to help us in determining how much of ::haskell builds with a given version of GHC.

Proposal
hackport already knows how to determine the minimum version of GHC required for a package.

  • Let's re-use that functionality to determine the maximum version of GHC required for a package to build.

  • Let's get hackport to methodically work its way through ::haskell, determining each package's maximum version (which will be based on the upper bounds of bundled libraries, such as base and containers) and writing out to a file.

  • Let's parse that file to determine the percentage of packages buildable with given versions of GHC. The file should be human-readable, such that we can work through the list of non-conformant packages, while also being able to be parsed to determine percentages of packages buildable with given versions of GHC.

Conclusion
I've given this only a very quick look, but I believe it shouldn't be too difficult to implement, given the basic plumbing is already there.

While this won't eliminate the need to physically test the build of packages, it will certainly give us a better idea of the state of ::haskell with regards to its proportion of compatible versions of GHC. Say, for example, we had 85% of ::haskell reporting as buildable with version x. That may give us the reasonable belief that, after testing critical packages for build failures, version x can be unmasked without going ahead and building the entirety of ::haskell.

The use case this seems to be most applicable to is the one we are in now: we are two versions of GHC behind upstream (granted, much of hackage hasn't moved on to the latest version, 8.10.1, either), but we are very much up to date with hackage, which hasn't always been the case.

A final word: if there is an easier way of getting the same result as above, I'm all ears.

Support hpack

hpack compiles package.yaml into *.cabal

stack uses hpack to compile package.yaml into *.cabal

I want hackport to use package.yaml instead of *.cabal so that I don't have to put *.cabal into my repository.

UTF-8 support

When hackport mergeing a package, which has utf-8 characters in its hackage description, the generated metadata.xml is invalid.

For example with hackport merge clash-ghc, the 2-byte λ (0x03bb) will become a 0x00bb. This byte sequence is no valid utf-8.

hackport no longer working

No matter what, hackport fails when I try to use merge or make-ebuild. I have tried deleting ~/.hackport, ~/.cabal, and deleting and re-cloning gentoo-haskell. I have also tried using app-portage/hackport-0.5.6 and app-portage/hackport-9999. Nothing seems to work. Here is the error I am getting:

hackport: Assertion failed
CalStack (from HasCallStack):
  assert, called at cabal/Cabal/Distribution/Simple/PackageIndex.hs:201:30 in main:Distribution.Simple.PackageIndex
  mkPackageIndex, called at cabal/Cabal/Distribution/Simple/PackageIndex.hs:215:17 in main:Distribution.Simple.PackageIndex

My guess is that the current commit of the cabal submodule is no longer compatible with Hackage.

Advanced metadata handling

We need to add additional features for metadata handling like adding new use flags information. Ping @qnikst for additional information.

Data.Map.insertWith' is gone. Use Data.Map.Strict.insertWith.

When building with ghc-8.6.3:

[181 of 294] Compiling Distribution.PackageDescription.Configuration ( cabal/Cabal/Distribution/PackageDescription/Configuration.hs, dist/build/hackport/hackport-tmp/Distribution/PackageDescription/Configuration.o )

cabal/Cabal/Distribution/PackageDescription/Configuration.hs:222:39: error:
    • Data.Map.insertWith' is gone. Use Data.Map.Strict.insertWith.
    • In the first argument of ‘Map.foldrWithKey’, namely
        ‘(Map.insertWith' combine)’
      In the expression:
        Map.foldrWithKey
          (Map.insertWith' combine) (unDepMapUnion xs) (unDepMapUnion ys)
      In an equation for ‘union’:
          union
            = Map.foldrWithKey
                (Map.insertWith' combine) (unDepMapUnion xs) (unDepMapUnion ys)
    |
222 |         let union = Map.foldrWithKey (Map.insertWith' combine)
    |                                       ^^^^^^^^^^^^^^^^^^^^^^^

hackport does not preserve IUSE renames in metadata.xml

See hackport merge cmark for an example. Hackport should preserve Cabal flag renames throughout an ebuild, e.g.:

pkgconfig -> system-cmark

We make hackport aware of this rename rule in #hackport: flags:, which is then used to apply the rule for future package bumps. In the case of cmark, whenever hackport sees the flag name pkgconfig it will replace it with system-cmark, as specified by the user.

As at 9fd0fd6 hackport ignores the flag rename rules when it writes the metadata.xml. This is a bug, because it generates invalid metadata.xml files. The solution is to pass rename-validated flags to the metadata.xml writer, which is not currently done.

hackport-0.6.4: status and list are broken

I recently updated to 0.6.4. merge works, update seems to do what it's supposed to, but I have issues with list and status.

list: It does the lookup as usual, but without the * indicating that it is present in the overlay.

status: I tried hackport status --from-hackage, and the result consists of color codes only, no package listed.

Handle multiple test-suite stanzas

This cabal file has multiple test-suite stanzas and only the dependencies from one are being added to the generated ebuild.

https://hackage.haskell.org/package/postgresql-simple-0.6.4/postgresql-simple.cabal :

test-suite inspection
  if !impl(ghc >=8.0)
    buildable: False

  default-language: Haskell2010
  type:             exitcode-stdio-1.0
  hs-source-dirs:   test
  main-is:          Inspection.hs
  build-depends:
      base
    , inspection-testing  >=0.4.1.1 && <0.5
    , postgresql-libpq
    , postgresql-simple
    , tasty
    , tasty-hunit

test-suite test
  default-language:   Haskell2010
  type:               exitcode-stdio-1.0
  hs-source-dirs:     test
  main-is:            Main.hs
  ...

inspection-testing was not added to the ebuild. This ends up with a failure during the configure phase, since cabal wants inspection-testing to be installed.

How to correctly handle stackage lts resolver

As far as I can see, hackport does not respect the resolver field in the stack.yaml. I think, this can lead to version incompatibilities.

See for example monad-logger, which depends on unliftio-core. Its package.yaml does not specify any particular version. The stack.yaml, though, specifies lts-14.22 and thus unliftio-core-0.1.2.0.

The latest version is unliftio-core-0.2.0.1. But this version introduced breaking changes. So now, when trying to build monad-logger against the latest unliftio-core, the build fails (due to askUnliftIo not being a method of class MonadUnliftIO any longer).

What is the correct way to ensure version compatibilities here?

Generate ebuilds using EAPI 7

The stable version of portage supports EAPI 7, so it might be a good idea to have hackport generate ebuilds using this. I presume that there might be updates needed to the eclasses as well in order to implement this, but I'm not sure at this point.

record-dot-preprocessor: Dependencies are missed

As you can see here, record-dot-preprocessor pulls in uniplate, however this is not added to the ebuild by hackport. I am running the latest hackport-9999 (b8a6814).

# hackport merge record-dot-preprocessor
accepting dep: ghc-8.4.3
Accepted depends: ["extra"]
Skipped depends: ["base >=4.8 && <5"]
Dead flags: []
Dropped flags: []
Active flags: []
Irrelevant flags: []
Current keywords: Nothing -> ["~amd64","~x86"]
Current license: Nothing -> Right "BSD"
Writing record-dot-preprocessor-0.2.7.ebuild
Recalculating digests...
Running repoman full --include-dev and pkgcheck scan...

RepoMan scours the neighborhood...
RepoMan sez: "If everyone were like you, I'd be out of business!"

Generated ebuild:

# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=7

# ebuild generated by hackport 0.6.7.9999

CABAL_FEATURES="lib profile haddock hoogle hscolour test-suite"
inherit haskell-cabal

DESCRIPTION="Preprocessor to allow record.field syntax"
HOMEPAGE="https://github.com/ndmitchell/record-dot-preprocessor#readme"
SRC_URI="https://hackage.haskell.org/package/${P}/${P}.tar.gz"

LICENSE="BSD"
SLOT="0/${PV}"
KEYWORDS="~amd64 ~x86"

RDEPEND="dev-haskell/extra:=[profile?]
	>=dev-lang/ghc-8.4.3:=
"
DEPEND="${RDEPEND}
	>=dev-haskell/cabal-2.2.0.1
	test? ( dev-haskell/record-hasfield )
"

Should hackport produce `IUSE=""`?

From the guidance I've received on #gentoo-dev-help, it seems that when IUSE is empty, it should be left out entirely.

Should we update hackport to do this?

Release v0.6 is missing from Hackage

Perhaps I'm jumping the gun, but I see that version 0.5.6 was released on May 30th, 2018, and uploaded to hackage also on May 30th, 2018. Github tells me that version 0.6 was released 15 days ago, but I don't see it on hackage. I anticipate that this is also why it is not yet in portage.

Is there a specific reason for the delay?

Updating metadata.xml to reflect flag descriptions from hackage

I find myself doing a lot of copy-pasting of flag names and descriptions from hackage.haskell.org into my metadata.xml files, mostly to make repoman happy. It seems like it would be pretty easy to convert the flag data from hackage and add this info to metadata.xml automatically.

The section of the metadata.xml I'm talking about looks like this:

<use>
     <flag name="buildexamples">Build examples</flag>
</use>

A typo in the readme and a few questions

the readme sais:
git clone git clone git://github.com/gentoo-haskell/gentoo-haskell.git
instead of:
git clone git://github.com/gentoo-haskell/gentoo-haskell.git

I'm using hackport-0.2.14 (installed from gentoo-haskell overlay), to make an ebuild for haskell-platform-2011.4.0.0 and I'm getting:

WARNING: Unknown build tool 'cabal-install'. Check the generated ebuild.

also the versions for alex and happy are not specified in the resulting ebuild (they exist in the .cabal file), are this expected behavior or I'm missig something?
I'm using .cabal file from here http://code.haskell.org/haskell-platform/haskell-platform.cabal
the cmd line(if matters)
$ hackport make-ebuild dev-haskell ~/overlay/haskell-platform.cabal

reading the haskell-platform-2011.2.0.1 ebuild I noticed that all dependencies are in RDEPEND, do I need to move the dependencies in DEPED to RDEPEND?

in the .cabal file hscolour and haddock are commented, do i need to add them?

thank you in advance :D

sorry the bad english an sorry if wrog place to ask these questions :/

Not in scope: type constructor or class ‘Semigroup’

[294 of 294] Compiling Main             ( Main.hs, dist/build/hackport/hackport-tmp/Main.dyn_o )

Main.hs:64:10: error:
    Not in scope: type constructor or class ‘Semigroup’
   |
64 | instance Semigroup ListFlags where
   |          ^^^^^^^^^

Main.hs:137:10: error:
    Not in scope: type constructor or class ‘Semigroup’
    |
137 | instance Semigroup MakeEbuildFlags where
    |          ^^^^^^^^^

Main.hs:209:10: error:
    Not in scope: type constructor or class ‘Semigroup’
    |
209 | instance Semigroup UpdateFlags where
    |          ^^^^^^^^^

Main.hs:323:10: error:
    Not in scope: type constructor or class ‘Semigroup’
    |
323 | instance Semigroup MergeFlags where
    |          ^^^^^^^^^

Add --refresh-metadata option

HackPort automatically generates the metadata.xml with USE flag entries for quite some time now. But if the USE flags of a package change, the maintainer must either delete the existing metadata.xml and run hackport merge again (and this only works if no USE flags have been deleted between versions) or the maintainer must manually edit the metadata.xml by hand.

A --refresh-metadata option (which is a commented TODO in the source code) could work like this:

  1. Force an overwrite of the existing metadata.xml, taking into account only the current package version. It therefore may create an invalid metadata.xml; or
  2. Overwrite the existing metadata.xml except for the USE flag entries, which will be overwritten by the union of all active USE flags across all package versions. This would be the preferred method.

hackport is incompatible with tar-0.4

I've tried to emerge hackport 0.5.1, but got compile error. It looks like I have incompatible tar library version (0.4.2.1).

[218 of 232] Compiling Hackage.Security.Client ( hackage-security/hackage-security/src/Hackage/Security/Client.hs, dist/build/hackport/hackport-tmp/Hackage/Security/Client.dyn_o )

hackage-security/hackage-security/src/Hackage/Security/Client.hs:533:66:
    Not in scope: ‘Tar.toList’
[219 of 232] Compiling Hackage.Security.Client.Repository.Cache ( hackage-security/hackage-security/src/Hackage/Security/Client/Repository/Cache.hs, dist/build/hackport/hackport-tmp/Hackage/Security/Client/Repository/Cache.dyn_o )

hackage-security/hackage-security/src/Hackage/Security/Client/Repository/Cache.hs:132:33:
    Not in scope: ‘TarIndex.empty’

hackage-security/hackage-security/src/Hackage/Security/Client/Repository/Cache.hs:133:33:
    Not in scope: ‘TarIndex.unfinalise’
    Perhaps you meant ‘TarIndex.serialise’ (imported from Codec.Archive.Tar.Index)

hackage-security/hackage-security/src/Hackage/Security/Client/Repository/Cache.hs:198:40:
    Not in scope: ‘TarIndex.finalise’
    Perhaps you meant ‘TarIndex.serialise’ (imported from Codec.Archive.Tar.Index)

Proposed fix: set required tar version >= 0.4.5.0 in hackport.cabal.

Space leak on `hackport merge accelerate-examples` and other packages with many flags

I'm using the latest hackport-9999 and when I run hackport merge accelerate-examples from within the gentoo-haskell tree, it spins for a while, maxing out a core and eating up more and more memory, and then exits with "Killed". I have had no problems when I run hackport merge for other packages.

# hackport merge accelerate-examples
rejecting dep: ghc-7.4.1 as ["base >=4.7 && <4.13","containers >=0.5"] were not found.
rejecting dep: ghc-7.4.2 as ["base >=4.7 && <4.13","containers >=0.5"] were not found.
rejecting dep: ghc-7.6.1 as ["base >=4.7 && <4.13"] were not found.
rejecting dep: ghc-7.6.2 as ["base >=4.7 && <4.13"] were not found.
accepting dep: ghc-7.8.2
Accepted depends: ["HUnit >=1.2","QuickCheck >=2.7","accelerate >=1.2 && >=1.2
&& >=1.2 && >=1.2 && >=1.2 && >=1.2 && >=1.2 && >=1.2 && >=1.2 && >=1.2 &&
>=1.2 && >=1.2 && >=1.2 && >=1.2","accelerate-fft >=1.2 &&
>=1.2","accelerate-io >=1.1 && >=1.2 && >=1.2 && >=1.2 && >=1.2 &&
>=1.2","accelerate-llvm-native >=1.2","accelerate-llvm-ptx
>=1.2","ansi-wl-pprint >=0.6","bmp >=1.2","bytestring-lexing >=0.5","cereal
>=0.3","colour-accelerate >=0.1 && >=0.1 && >=0.1 && >=0.1 && >=0.1 && >=0.1
&& >=0.1","criterion >=1.0 && >=1.0","criterion-measurement >=0.1","fclabels
>=2.0 && >=2.0 && >=2.0 && >=2.0 && >=2.0 && >=2.0 && >=2.0 && >=2.0 && >=2.0
&& >=2.0 && >=2.0 && >=1.0 && >=1.0 && >=1.0","gloss >=1.7 && >=1.9 && >=1.7
&& >=1.7 && >=1.8","gloss-accelerate >=2.0 && >=2.0 &&
>=2.0","gloss-raster-accelerate >=2.0 && >=2.0 && >=2.0","gloss-rendering
>=1.9","lens-accelerate >=0.1 && >=0.1 && >=0.1","linear
>=1.1","linear-accelerate >=0.3 && >=0.3 && >=0.3","matrix-market-attoparsec
>=0.1","mwc-random >=0.8 && >=0.8 && >=0.8 && >=0.8 &&
>=0.8","normaldistribution -any","random -any","repa >=3.1","repa-io
>=3.1","scientific >=0.3","test-framework >=0.5","test-framework-hunit
>=0.3","test-framework-quickcheck2 >=0.2","vector >=0.7 && >=0.7 &&
>=0.9","vector-algorithms >=0.4 && >=0.5.4"]
Skipped depends: ["accelerate-examples -any && -any && -any && -any && -any &&
-any && -any && -any && -any && -any && -any && -any && -any","base (>=4.7 &&
<4.13) && (>=4.7 && <4.13) && (>=4.7 && <4.13) && (>=4.7 && <4.13) && (>=4.7
&& <4.13) && (>=4.7 && <4.13) && (>=4.7 && <4.13) && (>=4.7 && <4.13) &&
(>=4.7 && <4.13) && (>=4.7 && <4.13) && (>=4.7 && <4.13) && (>=4.7 && <4.13)
&& (>=4.7 && <4.13) && >=4.7 && <4.13","binary >=0.7","bytestring >=0.9 &&
>=0.9.2","containers >=0.5 && >=0.4.2","directory >=1.1 && >=1.1 &&
>=1.1","filepath >=1.0"]
Dead flags: []
Dropped flags: []
Active flags:
["gui","ekg","codespeed","llvm-cpu","llvm-ptx","smvm","crystal","tunnel","canny","mandelbrot","fluid","nbody","smoothlife","hashcat","fft","pagerank","ray","kmeans"]
Killed

hackport 0.4.5 requires mtl >= 2.2

With mtl 2.1.2 (current stable in gentoo repo), the build fails, looks like it was added in 2.2:

Merge.hs:6:8:
    Could not find module ‘Control.Monad.Except’
    Perhaps you meant
      Control.Monad.Cont (from mtl-2.1.2)
      Control.Monad.Error (from mtl-2.1.2)
      Control.Monad.List (from mtl-2.1.2)
    Use -v to see a list of the files searched for.

Generate BDEPEND field in ebuilds

EAPI 7 split DEPEND into DEPEND and BDEPEND. I'm not familiar with cross-compiling, but would there be any benefit to the Gentoo Haskell ecosystem in generating this split in ebuilds?

From a cursory glance it seems that the change would simply be from (EDIT: add ghc dependency under RDEPEND and BDEPEND)

RDEPEND="dev-lang/ghc-<version>
"
DEPEND="${RDEPEND}
    dev-haskell/cabal
    test? ( dev-haskell/quickcheck )
"

to

RDEPEND="dev-lang/ghc-<version>
"
DEPEND="${RDEPEND}"
BDEPEND="dev-haskell/cabal
    dev-lang/ghc-<version>
    test? ( dev-haskell/quickcheck )
"

I haven't looked at the changes required (although I don't imagine them to be extensive), but I'd be happy to give this a go if it's worthwhile.

EDIT: It seems to me that we would also need to duplicate the dependency on ghc under BDEPEND so that the build machine has access to the compiler. To my understanding, we currently put ghc under RDEPEND due to its bundled core libraries, and since RDEPEND and DEPEND assume that they are referring to CHOST rather than CBUILD, this is not an issue if we don't utilise BDEPEND.

hackport uses := slot operator under '||' dep clause.

  dependency.badslotop [fatal]  4
   dev-haskell/cabal-helper/cabal-helper-0.8.2.0.ebuild: RDEPEND: '>=dev-haskell/cabal-1.14:=[profile?]' uses ':=' slot operator under '||' dep clause.
   dev-haskell/cabal-helper/cabal-helper-0.8.2.0.ebuild: RDEPEND: '<dev-haskell/cabal-1.26:=[profile?]' uses ':=' slot operator under '||' dep clause.
   dev-haskell/cabal-helper/cabal-helper-0.8.2.0.ebuild: RDEPEND: '>=dev-haskell/cabal-2.0:=[profile?]' uses ':=' slot operator under '||' dep clause.
   dev-haskell/cabal-helper/cabal-helper-0.8.2.0.ebuild: RDEPEND: '<dev-haskell/cabal-2.5:=[profile?]' uses ':=' slot operator under '||' dep clause.

Could not deduce (Semigroup (ComponentDeps a))

building master with ghc-8.4.3:

[  5 of 122] Compiling Distribution.Client.ComponentDeps ( cabal/cabal-install/Distribution/Client/ComponentDeps.hs, dist/build/hackport/hackport-tmp/Distribution/Client/ComponentDeps.o )

cabal/cabal-install/Distribution/Client/ComponentDeps.hs:65:10: error:
    • Could not deduce (Semigroup (ComponentDeps a))
        arising from the superclasses of an instance declaration
      from the context: Monoid a
        bound by the instance declaration
        at cabal/cabal-install/Distribution/Client/ComponentDeps.hs:65:10-45
    • In the instance declaration for ‘Monoid (ComponentDeps a)’
   |
65 | instance Monoid a => Monoid (ComponentDeps a) where
   |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[ 17 of 122] Compiling Distribution.Lex ( cabal/Cabal/Distribution/Lex.hs, dist/build/hackport/hackport-tmp/Distribution/Lex.o )

cabal/Cabal/Distribution/Lex.hs:30:10: error:
    • No instance for (Semigroup (DList a))
        arising from the superclasses of an instance declaration
    • In the instance declaration for ‘Monoid (DList a)’
   |
30 | instance Monoid (DList a) where
   |          ^^^^^^^^^^^^^^^^
[ 20 of 122] Compiling Distribution.Simple.CCompiler ( cabal/Cabal/Distribution/Simple/CCompiler.hs, dist/build/hackport/hackport-tmp/Distribution/Simple/CCompiler.o )

cabal/Cabal/Distribution/Simple/CCompiler.hs:67:10: error:
    • No instance for (Semigroup CDialect)
        arising from the superclasses of an instance declaration
    • In the instance declaration for ‘Monoid CDialect’
   |
67 | instance Monoid CDialect where
   |          ^^^^^^^^^^^^^^^
[ 25 of 122] Compiling Distribution.System ( cabal/Cabal/Distribution/System.hs, dist/build/hackport/hackport-tmp/Distribution/System.o )

cabal/Cabal/Distribution/System.hs:180:39: error:
    Ambiguous occurrence ‘<>’
    It could refer to either ‘Prelude.<>’,
                             imported from ‘Prelude’ at cabal/Cabal/Distribution/System.hs:19:8-26
                             (and originally defined in ‘GHC.Base’)
                          or ‘Text.PrettyPrint.<>’,
                             imported from ‘Text.PrettyPrint’ at cabal/Cabal/Distribution/System.hs:45:26-29
                             (and originally defined in ‘Text.PrettyPrint.HughesPJ’)
    |
180 |   disp (Platform arch os) = disp arch <> Disp.char '-' <> disp os
    |                                       ^^

cabal/Cabal/Distribution/System.hs:180:56: error:
    Ambiguous occurrence ‘<>’
    It could refer to either ‘Prelude.<>’,
                             imported from ‘Prelude’ at cabal/Cabal/Distribution/System.hs:19:8-26
                             (and originally defined in ‘GHC.Base’)
                          or ‘Text.PrettyPrint.<>’,
                             imported from ‘Text.PrettyPrint’ at cabal/Cabal/Distribution/System.hs:45:26-29
                             (and originally defined in ‘Text.PrettyPrint.HughesPJ’)
    |
180 |   disp (Platform arch os) = disp arch <> Disp.char '-' <> disp os
    |                                                        ^^
[ 29 of 122] Compiling Distribution.Version ( cabal/Cabal/Distribution/Version.hs, dist/build/hackport/hackport-tmp/Distribution/Version.o )

cabal/Cabal/Distribution/Version.hs:740:37: error:
    Ambiguous occurrence ‘<>’
    It could refer to either ‘Prelude.<>’,
                             imported from ‘Prelude’ at cabal/Cabal/Distribution/Version.hs:22:8-27
                             (and originally defined in ‘GHC.Base’)
                          or ‘Text.PrettyPrint.<>’,
                             imported from ‘Text.PrettyPrint’ at cabal/Cabal/Distribution/Version.hs:88:26-29
                             (and originally defined in ‘Text.PrettyPrint.HughesPJ’)
    |
740 |            (\v   -> (Disp.text "==" <> disp v                   , 0))
    |                                     ^^

cabal/Cabal/Distribution/Version.hs:741:37: error:
    Ambiguous occurrence ‘<>’
    It could refer to either ‘Prelude.<>’,
                             imported from ‘Prelude’ at cabal/Cabal/Distribution/Version.hs:22:8-27
                             (and originally defined in ‘GHC.Base’)
                          or ‘Text.PrettyPrint.<>’,
                             imported from ‘Text.PrettyPrint’ at cabal/Cabal/Distribution/Version.hs:88:26-29
                             (and originally defined in ‘Text.PrettyPrint.HughesPJ’)
    |
741 |            (\v   -> (Disp.char '>'  <> disp v                   , 0))
    |                                     ^^

cabal/Cabal/Distribution/Version.hs:742:37: error:
    Ambiguous occurrence ‘<>’
    It could refer to either ‘Prelude.<>’,
                             imported from ‘Prelude’ at cabal/Cabal/Distribution/Version.hs:22:8-27
                             (and originally defined in ‘GHC.Base’)
                          or ‘Text.PrettyPrint.<>’,
                             imported from ‘Text.PrettyPrint’ at cabal/Cabal/Distribution/Version.hs:88:26-29
                             (and originally defined in ‘Text.PrettyPrint.HughesPJ’)
    |
742 |            (\v   -> (Disp.char '<'  <> disp v                   , 0))
    |                                     ^^

cabal/Cabal/Distribution/Version.hs:743:37: error:
    Ambiguous occurrence ‘<>’
    It could refer to either ‘Prelude.<>’,
                             imported from ‘Prelude’ at cabal/Cabal/Distribution/Version.hs:22:8-27
                             (and originally defined in ‘GHC.Base’)
                          or ‘Text.PrettyPrint.<>’,
                             imported from ‘Text.PrettyPrint’ at cabal/Cabal/Distribution/Version.hs:88:26-29
                             (and originally defined in ‘Text.PrettyPrint.HughesPJ’)
    |
743 |            (\v   -> (Disp.text ">=" <> disp v                   , 0))
    |                                     ^^

cabal/Cabal/Distribution/Version.hs:744:37: error:
    Ambiguous occurrence ‘<>’
    It could refer to either ‘Prelude.<>’,
                             imported from ‘Prelude’ at cabal/Cabal/Distribution/Version.hs:22:8-27
                             (and originally defined in ‘GHC.Base’)
                          or ‘Text.PrettyPrint.<>’,
                             imported from ‘Text.PrettyPrint’ at cabal/Cabal/Distribution/Version.hs:88:26-29
                             (and originally defined in ‘Text.PrettyPrint.HughesPJ’)
    |
744 |            (\v   -> (Disp.text "<=" <> disp v                   , 0))
    |                                     ^^

cabal/Cabal/Distribution/Version.hs:745:37: error:
    Ambiguous occurrence ‘<>’
    It could refer to either ‘Prelude.<>’,
                             imported from ‘Prelude’ at cabal/Cabal/Distribution/Version.hs:22:8-27
                             (and originally defined in ‘GHC.Base’)
                          or ‘Text.PrettyPrint.<>’,
                             imported from ‘Text.PrettyPrint’ at cabal/Cabal/Distribution/Version.hs:88:26-29
                             (and originally defined in ‘Text.PrettyPrint.HughesPJ’)
    |
745 |            (\v _ -> (Disp.text "==" <> dispWild v               , 0))
    |                                     ^^

cabal/Cabal/Distribution/Version.hs:752:13: error:
    Ambiguous occurrence ‘<>’
    It could refer to either ‘Prelude.<>’,
                             imported from ‘Prelude’ at cabal/Cabal/Distribution/Version.hs:22:8-27
                             (and originally defined in ‘GHC.Base’)
                          or ‘Text.PrettyPrint.<>’,
                             imported from ‘Text.PrettyPrint’ at cabal/Cabal/Distribution/Version.hs:88:26-29
                             (and originally defined in ‘Text.PrettyPrint.HughesPJ’)
    |
752 |             <> Disp.text ".*"
    |             ^^

doesn't build

$ cabal build hackport
Preprocessing executable 'hackport' for hackport-0.4.4...

Diff.hs:28:8:
    Could not find module ‘Distribution.Client.Utils’
    Perhaps you meant
      Distribution.Simple.Utils (needs flag -package Cabal-1.20.0.2)
      Distribution.Simple.Utils (needs flag -package Cabal-1.18.1.3)
    Use -v to see a list of the files searched for.

DistroMap.hs:47:8:
    Could not find module ‘Distribution.Verbosity’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

DistroMap.hs:49:8:
    Could not find module ‘Distribution.Client.Types’
    Use -v to see a list of the files searched for.

DistroMap.hs:54:18:
    Could not find module ‘Distribution.Client.PackageIndex’
    Perhaps you meant
      Distribution.Simple.PackageIndex (needs flag -package Cabal-1.20.0.2)
      Distribution.Simple.PackageIndex (needs flag -package Cabal-1.18.1.3)
    Use -v to see a list of the files searched for.

DistroMap.hs:55:18:
    Could not find module ‘Distribution.Client.IndexUtils’
    Use -v to see a list of the files searched for.

Merge.hs:26:18:
    Could not find module ‘Distribution.PackageDescription.Parse’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Portage/Cabal.hs:11:18:
    Could not find module ‘Distribution.License’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Portage/GHCCore.hs:13:8:
    Could not find module ‘Distribution.Simple.PackageIndex’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Portage/GHCCore.hs:14:8:
    Could not find module ‘Distribution.InstalledPackageInfo’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Portage/GHCCore.hs:16:8:
    Could not find module ‘Distribution.PackageDescription’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Portage/GHCCore.hs:17:8:
    Could not find module ‘Distribution.PackageDescription.Configuration’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Portage/GHCCore.hs:18:8:
    Could not find module ‘Distribution.Compiler’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Portage/GHCCore.hs:19:8:
    Could not find module ‘Distribution.System’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Portage/Overlay.hs:20:8:
    Could not find module ‘Distribution.Simple.Utils’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Portage/PackageId.hs:20:18:
    Could not find module ‘Distribution.Package’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Portage/Version.hs:20:18:
    Could not find module ‘Distribution.Version’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Portage/Version.hs:22:8:
    Could not find module ‘Distribution.Text’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Portage/Version.hs:24:18:
    Could not find module ‘Distribution.Compat.ReadP’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Main.hs:11:8:
    Could not find module ‘Distribution.Simple.Setup’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Main.hs:17:8:
    Could not find module ‘Distribution.ReadE’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Main.hs:18:8:
    Could not find module ‘Distribution.Simple.Command’
    It is a member of the hidden package ‘Cabal-1.18.1.3’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    It is a member of the hidden package ‘Cabal-1.20.0.2’.
    Perhaps you need to add ‘Cabal’ to the build-depends in your .cabal file.
    Use -v to see a list of the files searched for.

Main.hs:26:8:
    Could not find module ‘Distribution.Client.Update’
    Use -v to see a list of the files searched for.

Main.hs:50:18:
    Could not find module ‘Paths_cabal_install’
    Use -v to see a list of the files searched for.

add cabal test-suite support

we should add support for

test-suite tests[1]
build-depends: ...

it there is such a section in cabal file we should add IUSE="test"

src_configure() {
    cabal_src_configure $(use_enable test tests[1])
}

and all section depends should go to DEPEND in test?(...) section

hackport is unaware of USE_EXPAND when writing metadata.xml

Hackport treats USE_EXPAND flags as regular USE flags as regards the metadata.xml writer. For example, hackport merge hashtables contains a flag rename rule from sse42 to cpu_flags_x86_sse4_2. Hackport should realise that this is a USE_EXPAND and leave it out of the metadata.xml, but instead hackport writes cpu-flags-x86-sse4-2 to the metadata.xml.

A relatively static solution would be to populate a list of USE_EXPANDs we need to handle, and teach hackport to ignore them when writing the metadata.xml.

A more dynamic solution would be to construct a list of filenames (with file extensions stripped) returned by $(portageq get_repo_path / gentoo)/profiles/desc/, which contains the USE_EXPANDs from ::gentoo. Then we can check if a given flag name (after rename rules have been applied) contains a prefix equal to any element of our list of USE_EXPAND filenames. If so, we won't write it to the metadata.xml.

Support USE flags with inverted logic

dev-haskell/hledger-web supports the library-only useflag:

❯ q use -eD library-only
dev-haskell/hledger-web[library-only] Build for use with "yesod devel"

This appears to have a similar effect as the more popular useflag executable:

❯ q use -eD executable
dev-haskell/bytedump[executable] build executable file
dev-haskell/cpu[executable] build 'cpuid' tool
dev-haskell/highlighting-kate[executable] Build the Highlight executable.
dev-haskell/language-dot[executable] Build the `ppdot' executable
dev-haskell/skylighting[executable] Build the skylighting executable.
dev-haskell/skylighting-core[executable] Build the skylighting executable.
dev-haskell/texmath[executable] Compile test executable.
dev-haskell/zip-archive[executable] Build the Zip executable.
dev-php/agavi[executable] Install the "agavi" executable used to manage projects. This requires dev-php/phing, and may be omitted if you are (for example) deploying an existing site to a production server.
dev-haskell/bench-show[executable] Build executable as well as library
dev-haskell/bytedump[executable] build executable file
dev-haskell/citeproc[executable] Build citeproc executable
dev-haskell/cpu[executable] build 'cpuid' tool
dev-haskell/highlighter[executable] Install a "highlighter" executable
dev-haskell/highlighting-kate[executable] Build the Highlight executable.
dev-haskell/language-dot[executable] Build the `ppdot' executable
dev-haskell/skylighting[executable] Whether to build the skylighting program
dev-haskell/skylighting-core[executable] Build skylighting-extract tool
dev-haskell/texmath[executable] Compile test executable.
dev-haskell/zip-archive[executable] Build the Zip executable.

It would be nice if the useflags could be unified.

See-also: https://bugs.gentoo.org/show_bug.cgi?id=762256
See-also: https://bugs.gentoo.org/show_bug.cgi?id=762259

`cabal repl` doesn't work

How do you people run ghci for hackport?

hackport ‰ cabal repl
Build profile: -w ghc-8.10.1 -O1
In order, the following will be built (use -v for more details):
 - hackport-0.6.6 (exe:hackport) (ephemeral targets)
Preprocessing executable 'hackport' for hackport-0.6.6..
GHCi, version 8.10.1: https://www.haskell.org/ghc/  :? for help

<interactive>:1:1: error:
    attempting to use module ‘main:Prelude’ (hackage-security/hackage-security/src/Prelude.hs) which is not loaded
cabal: repl failed for exe:hackport from hackport-0.6.6.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.