I would like to start uploading Leksah to hackage again, but I really don't like that it will take something like 5x longer to build from hackage than it does from github because of the use of overloading.
The problem is there is no way for leksah to indicate in leksah.cabal that it does not want overloading to be enabled (since there is no cabal.project file). I don't like the idea of splitting the gi-* packages and creating lots of orphans.
So what if we added a haskell-gi-overloading package to hackage. This would have two branches 0.0.0.0 (meaning no overloading support) and 1.x.x.x (yes we want overloading). We don't need to put anything in these packages (it might need one module so it is not completely empty), but perhaps there is some code in haskell-gi-base only needed when using overloading that would make sense to put in the 1.x.x.x branch.
For cabal files that do not use overloading (like leksah.cabal) we would add:
build-depends: haskell-gi-overloading <1.0
One (probably bad) way to make it work would be to change the gi-*.cabal files to include:
if flag(overloaded-methods)
build-depends: haskell-gi-overloading >=1.0 && <1.1
if flag(overloaded-properties)
build-depends: haskell-gi-overloading >=1.0 && <1.1
if flag(overloaded-signals)
build-depends: haskell-gi-overloading >=1.0 && <1.1
The solver should switch off all the flags as they are set to automatic. I suspect it will have little impact on the speed of the cabal solver for packages without the <1.0 constraint, but switching off those three automatic flags on so many gi-* packages is likely to be really bad for the solver.
Instead could the code generation in the custom setup of the gi-* packages ask Cabal for the version of haskell-gi-overloading that is in the build plan (not the one in setup-depends of course) and disable output of the overloading code if the version is <1.0? So the flag settings would just have no impact when the version of haskell-gi-overloading in the build plan was <1.0.
If that is not possible, could we output #if MIN_VERSION_haskell_gi_overloading(1,0,0) around the offending overloading code?
I would like to start uploading Leksah to hackage again, but I really don't like that it will take something like 5x longer to build from hackage than it does from github because of the use of overloading.
The problem is there is no way for leksah to indicate in
leksah.cabalthat it does not want overloading to be enabled (since there is nocabal.projectfile). I don't like the idea of splitting thegi-*packages and creating lots of orphans.So what if we added a
haskell-gi-overloadingpackage to hackage. This would have two branches0.0.0.0(meaning no overloading support) and1.x.x.x(yes we want overloading). We don't need to put anything in these packages (it might need one module so it is not completely empty), but perhaps there is some code inhaskell-gi-baseonly needed when using overloading that would make sense to put in the 1.x.x.x branch.For cabal files that do not use overloading (like leksah.cabal) we would add:
One (probably bad) way to make it work would be to change the
gi-*.cabalfiles to include:The solver should switch off all the flags as they are set to automatic. I suspect it will have little impact on the speed of the cabal solver for packages without the
<1.0constraint, but switching off those three automatic flags on so manygi-*packages is likely to be really bad for the solver.Instead could the code generation in the custom setup of the
gi-*packages askCabalfor the version ofhaskell-gi-overloadingthat is in the build plan (not the one insetup-dependsof course) and disable output of the overloading code if the version is<1.0? So the flag settings would just have no impact when the version ofhaskell-gi-overloadingin the build plan was<1.0.If that is not possible, could we output
#if MIN_VERSION_haskell_gi_overloading(1,0,0)around the offending overloading code?