Open hvr opened 7 years ago
Thanks Herbert for pointing me to the compilation and versioning issues! While the PVP agreement seems to be questionable some for me to follow it precisely (I'm trying to use quite stable functions from a small set and the most of these functions are very old, but PVP has its pros and cons), I'll try to improve the support of the old GHC compilers, although I'm not quite sure whether, for example, GHC 7.4 supports the RecursiveDo extension (it probably had another name if I remember).
Best regards, David Sorokin
@dsorokin Sure, semantic versioning has its pros and cons, but the fact is that Hackage has this guideline (it's written right on the frontpage of http://hackage.haskell.org/, maybe we should make it more prominent?); That being said, if you're really confident (or maybe because you have access to information beyond what the PVP contract provides) that you're using a small set of stable entry points which won't change when major version increments are signalled, it may be tolerable to deviate from the Hackage guidelines. But it's a gamble: if the assumption turns out to be wrong, it will result in Hackage temporarily suffering a regression for all consumers of that package, and it causes me as Hackage Trustee more work, as I'll have to investigate asap to figure out which meta-data is at fault (unfortunately, this can't be fully automated as it's not always easy to figure out which package is to blame and/or avoid false positives, and we don't have unlimited computing resources, so it won't scale the bigger Hackage grows), perform emergency meta-data edits on Hackage (the more popular the package is, the more urgency there is to step in) which causes avoidable meta-data updates (grows the package index everybody has to download), and finally contact the author. Point in case: all 37 released versions of aivika
on Hackage will require a meta-data fixup.
So, from a risk assessment POV, that's what's at stake if you don't play it safe. :-)
As for extensions, if you declare them via other-extensions
in the .cabal file, you don't have to remember which GHC compiler supports them. The cabal solver will take care of it (and all the infrastructure that relies on it, such as the matrix builder), and it's more principled than encoding compiler properties via a base
version bound (follows the mantra to "test for features, not for versions"). NB: you don't have to support GHC 7.4 if you don't want to; I'm merely interested in the Meta-data to reasonably/accurately reflect the areas of the configuration-space that are (not) supported.
EDIT: typos and reworded
I uploaded modified packages aivika-transformers and aivika-distributed, where added, at least, the support of the old GHC 7.8 compiler. Thanks again.
@dsorokin thanks; I'll watch the buildbot, and do a batch of meta-data fixups on Hackage; I'll let you know if I notice something else
@dsorokin the most recent upload is still broken on GHC 7.4 even though it declares compatibility with base-4.5
:
Configuring component lib from aivika-5.0.1
Preprocessing library aivika-5.0.1...
Simulation/Aivika/Circuit.hs:2:14:
Warning: -XRecursiveDo is deprecated: use -XDoRec or pragma {-# LANGUAGE DoRec #-} instead
Simulation/Aivika/Composite.hs:2:37:
Warning: -XRecursiveDo is deprecated: use -XDoRec or pragma {-# LANGUAGE DoRec #-} instead
Simulation/Aivika/Dynamics/Extra.hs:2:14:
Warning: -XRecursiveDo is deprecated: use -XDoRec or pragma {-# LANGUAGE DoRec #-} instead
Simulation/Aivika/SystemDynamics.hs:2:28:
Warning: -XRecursiveDo is deprecated: use -XDoRec or pragma {-# LANGUAGE DoRec #-} instead
Simulation/Aivika/Transform.hs:2:14:
Warning: -XRecursiveDo is deprecated: use -XDoRec or pragma {-# LANGUAGE DoRec #-} instead
Simulation/Aivika/Internal/Dynamics.hs:2:14:
Warning: -XRecursiveDo is deprecated: use -XDoRec or pragma {-# LANGUAGE DoRec #-} instead
Simulation/Aivika/Internal/Event.hs:2:14:
Warning: -XRecursiveDo is deprecated: use -XDoRec or pragma {-# LANGUAGE DoRec #-} instead
Simulation/Aivika/Internal/Parameter.hs:2:14:
Warning: -XRecursiveDo is deprecated: use -XDoRec or pragma {-# LANGUAGE DoRec #-} instead
Simulation/Aivika/Internal/Simulation.hs:2:14:
Warning: -XRecursiveDo is deprecated: use -XDoRec or pragma {-# LANGUAGE DoRec #-} instead
[ 1 of 76] Compiling Simulation.Aivika.Table ( Simulation/Aivika/Table.hs, /tmp/matrix-worker/1480762658/dist-newstyle/build/x86_64-linux/ghc-7.4.2/aivika-5.0.1/build/Simulation/Aivika/Table.o )
[ 2 of 76] Compiling Simulation.Aivika.Vector ( Simulation/Aivika/Vector.hs, /tmp/matrix-worker/1480762658/dist-newstyle/build/x86_64-linux/ghc-7.4.2/aivika-5.0.1/build/Simulation/Aivika/Vector.o )
[ 3 of 76] Compiling Simulation.Aivika.PriorityQueue.Pure ( Simulation/Aivika/PriorityQueue/Pure.hs, /tmp/matrix-worker/1480762658/dist-newstyle/build/x86_64-linux/ghc-7.4.2/aivika-5.0.1/build/Simulation/Aivika/PriorityQueue/Pure.o )
[ 4 of 76] Compiling Simulation.Aivika.PriorityQueue ( Simulation/Aivika/PriorityQueue.hs, /tmp/matrix-worker/1480762658/dist-newstyle/build/x86_64-linux/ghc-7.4.2/aivika-5.0.1/build/Simulation/Aivika/PriorityQueue.o )
[ 5 of 76] Compiling Simulation.Aivika.Unboxed ( Simulation/Aivika/Unboxed.hs, /tmp/matrix-worker/1480762658/dist-newstyle/build/x86_64-linux/ghc-7.4.2/aivika-5.0.1/build/Simulation/Aivika/Unboxed.o )
[ 6 of 76] Compiling Simulation.Aivika.Vector.Unboxed ( Simulation/Aivika/Vector/Unboxed.hs, /tmp/matrix-worker/1480762658/dist-newstyle/build/x86_64-linux/ghc-7.4.2/aivika-5.0.1/build/Simulation/Aivika/Vector/Unboxed.o )
[ 7 of 76] Compiling Simulation.Aivika.DoubleLinkedList ( Simulation/Aivika/DoubleLinkedList.hs, /tmp/matrix-worker/1480762658/dist-newstyle/build/x86_64-linux/ghc-7.4.2/aivika-5.0.1/build/Simulation/Aivika/DoubleLinkedList.o )
[ 8 of 76] Compiling Simulation.Aivika.Statistics ( Simulation/Aivika/Statistics.hs, /tmp/matrix-worker/1480762658/dist-newstyle/build/x86_64-linux/ghc-7.4.2/aivika-5.0.1/build/Simulation/Aivika/Statistics.o )
[ 9 of 76] Compiling Simulation.Aivika.Generator ( Simulation/Aivika/Generator.hs, /tmp/matrix-worker/1480762658/dist-newstyle/build/x86_64-linux/ghc-7.4.2/aivika-5.0.1/build/Simulation/Aivika/Generator.o )
[10 of 76] Compiling Simulation.Aivika.Internal.Specs ( Simulation/Aivika/Internal/Specs.hs, /tmp/matrix-worker/1480762658/dist-newstyle/build/x86_64-linux/ghc-7.4.2/aivika-5.0.1/build/Simulation/Aivika/Internal/Specs.o )
[11 of 76] Compiling Simulation.Aivika.Specs ( Simulation/Aivika/Specs.hs, /tmp/matrix-worker/1480762658/dist-newstyle/build/x86_64-linux/ghc-7.4.2/aivika-5.0.1/build/Simulation/Aivika/Specs.o )
[12 of 76] Compiling Simulation.Aivika.Internal.Parameter ( Simulation/Aivika/Internal/Parameter.hs, /tmp/matrix-worker/1480762658/dist-newstyle/build/x86_64-linux/ghc-7.4.2/aivika-5.0.1/build/Simulation/Aivika/Internal/Parameter.o )
Simulation/Aivika/Internal/Parameter.hs:214:18:
parse error on input `<-'
Thanks Herbert again! It seems that now I have to update the version number of package base, or rewrite those parts directly with help of mfix.
By the way, today I fortunately decided to test with the old GHC 7.8 before uploading and caught a missed import error of Data.Monoid in the aivika-transformers package. I fixed it in time)
What version of the base package should I use to compile the code with GHC 7.6 and higher?
@dsorokin this here gives you a good overview:
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries/VersionHistory
IOW, use e.g. >= 4.6
as the lower bound if you want to support only GHC 7.6 and later (which is totally fine btw).
Also, are you aware of https://github.com/hvr/multi-ghc-travis/blob/master/make_travis_yml_2.hs ? That way you can have Travis test continously against all the GHC versions you want to support during development...
Thank you for the links!
I'm currently working on the next generation of http://matrix.hackage.haskell.org/ (which is not yet reachable publicly, hence the screenshot & pasted error messages) when
alvika
caught my eye...The build-dependencies have inaccurate versions bounds. Please be aware that accurate version bounds are mandated by the PVP, and adherence to the PVP is expected as part of the Hackage guidelines. This has various knock off consequences, such as Hackage possibly not being able to generate Haddock documentation for your package, install-plans degrading over time, as well generally resulting in a poor experience for users since they'll run into the same compilation errors.
The
cabal gen-bounds
command can be used to help infer an initial set of version bounds, see Cabal User Guide | Generating dependency version bounds for more details.If you have any questions, please let me know!
Specifically, I've noticed the following compile error
There's similiar problems in the other alvika-* packages; e.g. in
aivika-transformers
:or in
aivika-4.6
with GHC 7.4.2: