gentoo-haskell / hackport Goto Github PK
View Code? Open in Web Editor NEWA command line tool to generate Gentoo ebuilds from Hackage packages.
License: GNU General Public License v3.0
A command line tool to generate Gentoo ebuilds from Hackage packages.
License: GNU General Public License v3.0
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.
For example, it breaks repoman checks because clash happens to style itself as "CλaSH".
See the generated metadata.xml and fixed versions:
ahyangyi/ahyangyi-overlay@d25e94c
Add a support for searching for additional tag information in previous ebuilds, like:
# hackport: hide-use cocoa
to use them in hackport later
As an example, hackport merge cassava-0.5.2.0
does not generate the dependency list presented in the Test-suite
stanza in cassava.cabal
. Notice the capital "T" in Test-suite
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.
See detalis on https://bugs.gentoo.org/666314#c3 where generated description is:
DESCRIPTION="Reading, writing and manipulating \\"
Could be better, something like:
DESCRIPTION="Reading, writing and manipulating '.tar' archives."
For lower bounds use:
!<foo/bar-0.1.2
instead of:
>foo/bar-0.1.2:=[profile?]
This should be more dependency-resolution friendly.
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:
::haskell
::haskell
, including 'critical' packages detailed in the docsStep 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.
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.
When hackport merge
ing 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.
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.
I am re-opening gentoo-haskell/gentoo-haskell#861 here.
One idea is to have hackport fetch the latest .cabal and put it in $FILESDIR
, which could then be copied to $WORKDIR
during the prepare phase and used for the build. It just seems like this would be a more elegant solution than cabal_chdeps
, considering that there is more to a .cabal file than just a list of dependencies.
We need to add additional features for metadata handling like adding new use flags information. Ping @qnikst for additional information.
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)
| ^^^^^^^^^^^^^^^^^^^^^^^
If you look at the dependencies for http://hackage.haskell.org/package/sized-vector, you'll find "singletons (==0.8.* || >=1.0 && <1.2)". I ran "hackport -p . sized-vector" and got this line in RDEPEND:
">=dev-haskell/singletons-0.8:=[profile?] <dev-haskell/singletons-0.9:=[profile?]", but that rules out the current version 1.1.2, which is in the overlay and should work with that package.
Some packages use additional test flag and hackport creates incorrect dep list for them
As per haskell/hackage-server#611 it seems like hackport isn't picking up metadata revisions?
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.
Specifically, as of 0.6.7.9999
, hackport merge streamly-0.7.2
produces an incorrect upper-bound for dev-haskell/primitive
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.
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.
https://wiki.haskell.org/Shared_libraries_and_GHC says haskell shared libraries are 5 ~ 20 times as slow as inlined libraries.
https://hackage.haskell.org/package/deepseq-bounded
There are up to 4194304 possible flag combinations.
This may take a while.
Doesn't fit in 12GB of RAM.
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?
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.
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 )
"
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?
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?
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>
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 :/
[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
| ^^^^^^^^^
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:
metadata.xml
, taking into account only the current package version. It therefore may create an invalid metadata.xml
; ormetadata.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.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.
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
It generates it as dev-haskell/ghc
while ghc lives in dev-lang. For example, try hint
package from hackage.
Thus, hackport merge
stopped working.
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.
see gentoo-haskell/gentoo-haskell@aca5d5c for details.
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
.
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.
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 ".*"
| ^^
Another idea:
Add a man page for hackport
.
$ 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.
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 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_EXPAND
s 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_EXPAND
s 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
.
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
hackport merge converge-0.1.0.1
results in an ebuild with HOMEPAGE="/dev/null"
, which is exactly what is listed on hackage.
repoman flags this as an error.
Should hackport attempt to parse the URL and "do something else" if it is invalid?
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.
I think it would be a good idea going forward to have a readable configuration file for hackport
, for instance TOML. I personally like TOML because it was designed to be used for configuration files and there are Haskell libraries for parsing it.
As lots of time is spent on adding all those cabal_chdeps
manually every time ghc is bumped.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.