-
Notifications
You must be signed in to change notification settings - Fork 11
Split package-flags into flags used when testing and flags used for snapshot users #33
Comments
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 probably avoid some redundancy to have "testing-flags" override "snapshot-flags". OTOH that might be a bit confusing…
Can you expand on how to do that? Simply creating a test-suite that lists the executable modules as For threepenny-gui, it's probably not worth the hassle anyway… |
A main module does not need to be named |
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. |
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. |
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.
The text was updated successfully, but these errors were encountered: