Split package-flags into flags used when testing and flags used for snapshot users
Opened this issue · 5 comments
threepenny-gui has a cabal flag for compiling example executables. Currently adding the flag to package-flags will set it both when we run the nightly build and when snapshot users install the package. It would be nice to separate these into "testing-flags" and "snapshot-flags".
In the meantime a workaround is to compile the examples as part of a test-suite.
At least brick and fay have similar flags. It would be good to notify the maintainers of these packages once the separate flag settings have been implemented.
It would be nice to separate these into "testing-flags" and "snapshot-flags".
It would probably avoid some redundancy to have "testing-flags" override "snapshot-flags". OTOH that might be a bit confusing…
In the meantime a workaround is to compile the examples as part of a test-suite.
Can you expand on how to do that?
Simply creating a test-suite that lists the executable modules as other-modules might not work because they are basically all Main.
For threepenny-gui, it's probably not worth the hassle anyway…
A main module does not need to be named Main
I'm -1 on this: while this may be a nice convenience for some people wanting to get CI capabilities from Stackage, it means that - potentially - we'll be creating Stackage snapshots that cannot be compiled with Stack, due to a different and untested set of flags.
it means that - potentially - we'll be creating Stackage snapshots that cannot be compiled with Stack, due to a different and untested set of flags.
That's a good point.
Would it be possible to test both configurations then? Packages that depend on e.g. threepenny-gui need only be tested with the "snapshot-flags" configuration of course.
I'm unlikely to spend time on this, if someone wants to take a stab at it, I'll review. I'm not overly enthusiastic about this, since setting up a Travis cron job with a nightly resolver should give the same benefits without new code.