Open swamp-agr opened 3 years ago
fay-base
enabled. fay-base
.Options:
Option | Pros | Cons |
---|---|---|
Manual control (almost the same, but losing flag -ftest and dependency on fay-base ) |
few changes required | new contract for maintainers (almost the same as right now but a bit worse) |
Moving the whole test-suite and test sources to fay-base package |
few changes required | fay tests also will be moved to fay-base . fay will live without tests. |
Move the most tests to fay-base , leave a few tests in fay |
Both compiler and base will be covered |
average code changes: partial code overlap in test-suites, subject of moving test tool into fay library. |
Investigate new cabal features (dropping < 8.8 compilers support) and adopt them to move fay-base back inside fay |
If it is possible then the best of two worlds would be under one package, fay-base could be dropped |
It is an area of uncertainty: research required. Might be impossible. |
@swamp-agr thanks for your help in getting #469 resolved, and for opening this new issue.
I'm still struggling to get tests working, though, and I think it may be related to something in this bug report, or maybe #459 . Here is how you can reproduce my issue:
# Get the sources
cabal unpack fay
cd fay-0.24.2.0
ls # uh-oh, notice there's no fay-base here...
# Configure and build
ghc Setup.hs -o setup
./setup configure --flag=test
./setup build
# Try to run the tests
export LD_LIBRARY_PATH="${PWD}/dist/build"
./dist/build/fay-tests/fay-tests --num-threads/${nproc} -random 20
This results in many tests failing with ghc-pkg: cannot find package fay-base
If you think about it, this makes sense, as the release tarbal doesn't include fay-base, and the cabal files don't list it at all (you took it out, to resolve the circular dependency: thanks!)
Further investigation shows me how you worked around this on travis, i.e. you just manually install fay-base. However, I can't do this in gentoo, because it drops me right back into the circular dependency issue.
I've seen some packages (for example, parser-combinators
) split out tests into a separate package altogether (i.e. parser-combinators-tests
). I don't know their motivation for doing so, but it seems that this may be "cheap" for you to implement (fay-tests
is already a separate executable) and would resolve my circular dependency problem (I think!).
I don't love that option, though, as it separates the test from the code under test. I guess it is essentially what you've listed in row 2 in your table above.
As it was initially discussed in #469, there is circular dependencies between
fay
andfay-base
:fay-base
depends onfay
.fay-base
contains modules with same names as inbase
(Prelude
,Data.Maybe
and so on). In order to preventambiguous modules names
error, it was not exposed by default.fay-tests
executable which is hidden by flagtest
and disabled by default fromfay
package depends onfay-base
.Thus,
fay-tests
component could not be converted easily to enabledtest-suite
.During discussion in #469 there were 2 proposals opened in order to mitigate circular dependencies:
fay-base
intofay
package as a (separate) library. (multi-component packages are enabled only since cabal 3.0).I would prefer to keep two separate packages and relocate tests accordingly to their purpose (compiler or base library).